From noreply at sourceforge.net Thu Jul 1 00:33:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 00:33:13 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 11:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-06-30 21:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 21:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Thu Jul 1 02:18:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 02:18:32 2004 Subject: [Patches] [ python-Patches-983206 ] Allow ldshared to be overridden by environment var Message-ID: Patches item #983206, was opened at 2004-07-01 16: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=983206&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Liam Routt (liam_routt) Assigned to: Nobody/Anonymous (nobody) Summary: Allow ldshared to be overridden by environment var Initial Comment: At present the ldshared executible is set only by locating it in the python Makefile (there is a fallback if it is not found, as well). While that works in many cases, it may be that one needs to set the ldshared to agree with a compiler/linker other than the one python was compiled with. You can set CC, but when creating shared objects you are stuck with whatever python was compiled with. The patch simply checks for LDSHARED in the current environment, and if it is present, it uses it. This is the same behaviour (and method) as for CC and CXX. Note that I'm indicating this is for 2.3, but I've browsed CVS and found sysconfig.py to be identical in this area of the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983206&group_id=5470 From noreply at sourceforge.net Thu Jul 1 02:48:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 02:48:43 2004 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-14 23:57 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: sha256 module Initial Comment: This module is a copy of shamodule.c, with the SHA-1 compression function replaced with the SHA-256 compression function (copied from the LibTomCrypt public-domain crypto library). SHA-256 is similar to SHA-1: it's a US Federal Standard hash algorithm (FIPS 180-2). The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). There's other flavors of SHA, but they're not as useful: SHA-384 and SHA-512 are defined on 64-bit values, so are slow on 32-bit architectures. SHA-224 is just silly (it saves 32 bits over SHA-256; that's its sole rationale). ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-06-30 23:48 Message: Logged In: YES user_id=973611 I'm uploading an attempt at documentation for this module. I had trouble installing the tex tools so I'm not sure if it's correct, but it should be easy to fix if not. I'll try to straighten myself out with the tools so I can make sure. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 07:23 Message: Logged In: YES user_id=11375 I can't rule on whether the module should be added or not, so I'll bring it up on python-dev. Feel free to join the resulting thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From noreply at sourceforge.net Thu Jul 1 15:39:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 15:39:52 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 05:26 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-01 21:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Thu Jul 1 15:59:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 16:21:29 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 05:26 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-01 21:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Thu Jul 1 17:40:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 17:41:01 2004 Subject: [Patches] [ python-Patches-972991 ] fix build of docs in info format Message-ID: Patches item #972991, was opened at 2004-06-15 05:47 Message generated for change (Comment added) made by chomo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: fix build of docs in info format Initial Comment: one of those a workaround in py2texi.el (verbatim environments are processed before comments) ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-07-01 21:40 Message: Logged In: YES user_id=943591 need more documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 From noreply at sourceforge.net Thu Jul 1 19:19:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 19:19:59 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 13:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-07-02 09:19 Message: Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-02 05:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-02 05:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Thu Jul 1 19:56:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 19:56:31 2004 Subject: [Patches] [ python-Patches-983775 ] Allow bdist_wininst to install for non-admin users Message-ID: Patches item #983775, was opened at 2004-07-02 09:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983775&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: Allow bdist_wininst to install for non-admin users Initial Comment: Attached is a patch which allows a distutils binary installation to work when Python is installed by a non-admin, and the extension is also to be installed by a non-admin user. It makes the following changes: * When enumerating the Python versions found, also remember the HKEY they were found under. * When installing, if Python was installed under HKCU, we will too. If Python was installed under HKLM, we check the permissions of the current user, and install where we can. * The "root" key we use is a global variable - all registry setting and delete functions use this global rather than a hardcoded HKLM. * A new entry is written to the install log, indicating the key we used. Uninstallation is based on this key. Another change in this patch is that 'tempnam()' is used rather than 'tmpnam()' - 'tmpnam' creates a temp file on the root of the current drive, and if this is readonly would explain the 'freopen' errors occasionally reported. 'tempnam' creates the temp file in the %TEMP% directory. I've tested this when Python is installed by an admin, but the person installing the extension does *not* have admin permissions. Assuming the user has write permissions into the Python directory, this works correctly. As usual, assigning to Thomas for comment/review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983775&group_id=5470 From noreply at sourceforge.net Thu Jul 1 23:04:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 1 23:04:19 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 14:43 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-01 23:04 Message: Logged In: YES user_id=31435 Brett, it looks like self.__stderr is never given a value -- the __init__ code here binds a *local* vrbl __stderr to _sys.stderr. If so, that tells me the bulk of the patch hasn't actually been exercised (else it would have raised AttributeError trying to print to self.__stderr). To simplify it more, I think it would be fine to ignore sys.tracebacklimit. A Google search shows that virtually the only use of sys.tracebacklimit in real life is the use made of it here: passively accessing its value to simulate what it would have done if anyone had ever bothered to set it (of which I couldn't find even one example). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-01 00:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-17 00:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Fri Jul 2 03:04:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 03:04:43 2004 Subject: [Patches] [ python-Patches-663482 ] 658254: accept None for time.ctime() and friends Message-ID: Patches item #663482, was opened at 2003-01-06 22:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 658254: accept None for time.ctime() and friends Initial Comment: ctime(), gmtime(), and localtime() now support None and treat it as tho you passed no arguments at all. i am new to patching for py and am not sure if there are unit tests i should update. please advise... ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-02 02:04 Message: Logged In: YES user_id=80475 Fred, here is Blunk's patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 15:38 Message: Logged In: YES user_id=357491 What do people think of this functionality? I personally don't see a need for it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 17:33 Message: Logged In: YES user_id=33168 There don't appear to be any direct tests, but it would still be nice to call the functions and verify they work ok. You could compare that abs(ctime() - ctime(None)) < .5, for example. Look in Lib/test/test_time.py. Also, the docs need to be updated, see Doc/lib/libtime.tex. That should be updated, ie change \optional(secs) with \optional{secs\code{ = None}}. Also, an entry in Misc/NEWS should be added since this is an API change. There is no attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 From noreply at sourceforge.net Fri Jul 2 04:00:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 04:01:11 2004 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-14 23:57 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: sha256 module Initial Comment: This module is a copy of shamodule.c, with the SHA-1 compression function replaced with the SHA-256 compression function (copied from the LibTomCrypt public-domain crypto library). SHA-256 is similar to SHA-1: it's a US Federal Standard hash algorithm (FIPS 180-2). The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). There's other flavors of SHA, but they're not as useful: SHA-384 and SHA-512 are defined on 64-bit values, so are slow on 32-bit architectures. SHA-224 is just silly (it saves 32 bits over SHA-256; that's its sole rationale). ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-07-02 01:00 Message: Logged In: YES user_id=973611 Uploading a new sha256 module with a sha224 function, and a sha512 module with a sha384 function. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-06-30 23:48 Message: Logged In: YES user_id=973611 I'm uploading an attempt at documentation for this module. I had trouble installing the tex tools so I'm not sure if it's correct, but it should be easy to fix if not. I'll try to straighten myself out with the tools so I can make sure. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 07:23 Message: Logged In: YES user_id=11375 I can't rule on whether the module should be added or not, so I'll bring it up on python-dev. Feel free to join the resulting thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From noreply at sourceforge.net Fri Jul 2 09:44:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 09:44:40 2004 Subject: [Patches] [ python-Patches-909005 ] asyncore fixes and improvements Message-ID: Patches item #909005, was opened at 2004-03-03 16:07 Message generated for change (Comment added) made by klimkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Klimkin (klimkin) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore fixes and improvements Initial Comment: Minor: * 0/1 for boolean values replaced with False/True. * (887279) Added handling of POLLPRI as POLLIN. POLLERR, POLLHUP, POLLNVAL are handled as exception event. handle_expt_event gets recent error from self.socket object and raises socket.error. * Default readable()/writable() returns False. * Added "map" parameter for file_dispatcher. * file_wrapper: removed "return" in close(), recv/read and send/write swapped because of their nature. * mac code for writable() removed. Manual for accept() on mac is similar to the one on linux. * Repeating exception changed from "raise socket.error, why" to raise. * Added connected/accepting/addr reset on close(). Initialization of variables moved to __init__. * close_all() now calls close for dispatcher object, EBADF treated as already closed socket/file. * Added channel id to "unhandled..." messages. Bugs: * Fixed bug (654766,889153): client never gets connected, nor errored. Connecting client gets writable event from select(), however, some client may want always be non writable. Such client may never get connected. The fix adds _readable() - always True for accepting and always False for connecting socket; and _writable() - always False for accepting and always True for connecting socket. This implies, that listening dispatcher's readable() and writable() will never be called. ("man accept" and "man connect" for non-blocking sockets). * Fixed bug: error handling after accept(). It's said, that accept can return EWOULDBLOCK even for readable socket. This mean, that even after handle_accept(), dispatcher's accept() still raise EWOULDBLOCK. New code does accept() itself and stores accepted socket in self.__pending_accept. If there was socket.error, it's treated as EWOULDBLOCK. dispatcher's accept returns self.__pending_accept and resets it to None. Features: * Added pending_read() and pending_write(). The functions helps to use dispatcher over non socket objects with buffering capabilities. In original dispatcher, if socket makes buffered read and some data is in buffer, entering asyncore.poll() doesn't finishes, since there is no data in real file/socket. This feature allow to use SSL socket, since the socket reads data by 16k chunks. ---------------------------------------------------------------------- >Comment By: Alexey Klimkin (klimkin) Date: 2004-07-02 17:44 Message: Logged In: YES user_id=410460 In addition to "[ 909005 ] asyncore fixes and improvements" and CVS version "asyncore.py,v 2.51" this patch provides: * Added handling of buffered socket layer (pending_read(), pending_write()). * Added fd number for __repr__. * Initialized self.socket = socket._closedsocket() instead of None for verbose error output (like closed socket.socket). * asyncore and asynchat implements idispatcher and iasync_chat. * Fixed self.addr initialization. * Removed import exceptions. * Don't filter KeyboardInterrupt, just pass through. * Added queue of sockets, solves the problem of select() on too many descriptors. I have run make test in python cvs distrib without problems. Examples of using i* included. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-05 21:54 Message: Logged In: YES user_id=11375 I've struggled to get the test suite running without errors on my machine, but have failed. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-22 09:15 Message: Logged In: YES user_id=410460 There is no real reason for this change, please undo. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:18 Message: Logged In: YES user_id=11375 In your version of file_dispatch.__init__, the .set_file() call is moved earlier; can you say why? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:13 Message: Logged In: YES user_id=11375 Added "map" parameter for file_dispatcher and dispatcher_with_send in CVS HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:08 Message: Logged In: YES user_id=11375 Repeating exception changes ('raise socket.error' -> just 'raise') checked into HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:02 Message: Logged In: YES user_id=11375 Mac code for writable() removed from HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 23:02 Message: Logged In: YES user_id=11375 Patch to use True/False applied to HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 22:55 Message: Logged In: YES user_id=11375 Fix for bug #887279 applied to HEAD. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-03-21 22:48 Message: Logged In: YES user_id=11375 The many number of changes in this patch make it difficult to figure out which changes fix which problem. I've created a new directory in CVS, nondist/sandbox/asyncore, that contains copies of the module with these patches applied, and will work on applying changes to the copy in dist/src. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-17 10:15 Message: Logged In: YES user_id=410460 Sorry, unfortunately I have lost old patch file. I have atached new one. In addition to fixes, listed above, the patch includes: 1. Fix for operating on uninitialized socket. self.socket now initializes with _closed_socket(), so any operation throws EBADF. 2. Added class idispatcher - base class for dispatcher. The purpose of this class is to allow simple replacement of media(dispatcher interface) in classes, derived from dispatcher class. This is based on 'object'. I have also attached asynchat.diff - example for new-style dispatcher. Old asynchat works as well. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-03-11 18:49 Message: Logged In: YES user_id=9205 There is no file attached! You have to click on the checkbox next to the upload filename. This is a Sourceforge annoyance :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470 From noreply at sourceforge.net Fri Jul 2 12:08:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 12:08:23 2004 Subject: [Patches] [ python-Patches-983019 ] Making weakref.ref subclassable Message-ID: Patches item #983019, was opened at 2004-06-30 17:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983019&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Making weakref.ref subclassable Initial Comment: This patch makes weak references subclassable. This includes the following changes: - weakref.ref and weakref.ReferenceType will become aliases for each other - weakref.ref will be a modern, new-style class with proper __new__ and __init__ methods - weakref.WeakValueDictionary will have a lighter memory footprint, using a new weakref.ref subclass to associate the key with the value, allowing us to have only a single object of overhead for each dictionary entry (currently, there are 3 objects of overhead per entry: a weakref to the value, a weakref to the dictionary, and a function object used as a weakref callback; the weakref to the dictionary could be avoided without this change) - a new macro, PyWeakref_CheckRefExact(), will be added - PyWeakref_CheckRef() will check for subclasses of weakref.ref - the cyclic garbage detector will be affected by the change to PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the unreachable list that do not have finalizers (in the move_troublemakers() function). This should only happen for weakref objects which are not of one of the "standard" three types (ref, proxy, and callable proxy). For debug builds, it will also affect assertions in the clear_weakerfs() and release_weakrefs() functions. The change to the cyclic garbage detector probably carries the most risk, and that only because the potential for a performance penalty. Running the Zope 3 test suite did not show any clear change in performance, and a key subsystem in Zope (zope.interface) uses weakrefs extensively. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-02 12:08 Message: Logged In: YES user_id=3066 Added LaTeX documentation as a separate patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983019&group_id=5470 From noreply at sourceforge.net Fri Jul 2 14:17:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 14:18:17 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 2 15:02:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 15:02:10 2004 Subject: [Patches] [ python-Patches-983019 ] Making weakref.ref subclassable Message-ID: Patches item #983019, was opened at 2004-06-30 17:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983019&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Making weakref.ref subclassable Initial Comment: This patch makes weak references subclassable. This includes the following changes: - weakref.ref and weakref.ReferenceType will become aliases for each other - weakref.ref will be a modern, new-style class with proper __new__ and __init__ methods - weakref.WeakValueDictionary will have a lighter memory footprint, using a new weakref.ref subclass to associate the key with the value, allowing us to have only a single object of overhead for each dictionary entry (currently, there are 3 objects of overhead per entry: a weakref to the value, a weakref to the dictionary, and a function object used as a weakref callback; the weakref to the dictionary could be avoided without this change) - a new macro, PyWeakref_CheckRefExact(), will be added - PyWeakref_CheckRef() will check for subclasses of weakref.ref - the cyclic garbage detector will be affected by the change to PyWeakref_CheckRef(); it will potentially call issubtype() for objects in the unreachable list that do not have finalizers (in the move_troublemakers() function). This should only happen for weakref objects which are not of one of the "standard" three types (ref, proxy, and callable proxy). For debug builds, it will also affect assertions in the clear_weakerfs() and release_weakrefs() functions. The change to the cyclic garbage detector probably carries the most risk, and that only because the potential for a performance penalty. Running the Zope 3 test suite did not show any clear change in performance, and a key subsystem in Zope (zope.interface) uses weakrefs extensively. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-02 15:02 Message: Logged In: YES user_id=3066 Committed for Python 2.4: Doc/lib/libweakref.tex 1.27 Include/weakrefobject.h 1.5 Lib/test/test_weakref.py 1.41 Lib/weakref.py 1.23 Misc/NEWS 1.1020 Modules/_weakref.c 1.19 Objects/object.c 2.219 Objects/weakrefobject.c 1.17 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-02 12:08 Message: Logged In: YES user_id=3066 Added LaTeX documentation as a separate patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983019&group_id=5470 From noreply at sourceforge.net Fri Jul 2 15:34:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 15:34:19 2004 Subject: [Patches] [ python-Patches-983775 ] Allow bdist_wininst to install for non-admin users Message-ID: Patches item #983775, was opened at 2004-07-02 01:56 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983775&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: Allow bdist_wininst to install for non-admin users Initial Comment: Attached is a patch which allows a distutils binary installation to work when Python is installed by a non-admin, and the extension is also to be installed by a non-admin user. It makes the following changes: * When enumerating the Python versions found, also remember the HKEY they were found under. * When installing, if Python was installed under HKCU, we will too. If Python was installed under HKLM, we check the permissions of the current user, and install where we can. * The "root" key we use is a global variable - all registry setting and delete functions use this global rather than a hardcoded HKLM. * A new entry is written to the install log, indicating the key we used. Uninstallation is based on this key. Another change in this patch is that 'tempnam()' is used rather than 'tmpnam()' - 'tmpnam' creates a temp file on the root of the current drive, and if this is readonly would explain the 'freopen' errors occasionally reported. 'tempnam' creates the temp file in the %TEMP% directory. I've tested this when Python is installed by an admin, but the person installing the extension does *not* have admin permissions. Assuming the user has write permissions into the Python directory, this works correctly. As usual, assigning to Thomas for comment/review. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-02 21:34 Message: Logged In: YES user_id=11105 I have read but not tested your patch. Except that I assume pywin32 build 202 installer already uses it, and it installed fine for me. It would be great if you check this in, probably these related old bugs can also be closed then: http://www.python.org/sf/555810 http://www.python.org/sf/555812 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983775&group_id=5470 From noreply at sourceforge.net Fri Jul 2 19:54:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 19:54:21 2004 Subject: [Patches] [ python-Patches-983775 ] Allow bdist_wininst to install for non-admin users Message-ID: Patches item #983775, was opened at 2004-07-02 09:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983775&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow bdist_wininst to install for non-admin users Initial Comment: Attached is a patch which allows a distutils binary installation to work when Python is installed by a non-admin, and the extension is also to be installed by a non-admin user. It makes the following changes: * When enumerating the Python versions found, also remember the HKEY they were found under. * When installing, if Python was installed under HKCU, we will too. If Python was installed under HKLM, we check the permissions of the current user, and install where we can. * The "root" key we use is a global variable - all registry setting and delete functions use this global rather than a hardcoded HKLM. * A new entry is written to the install log, indicating the key we used. Uninstallation is based on this key. Another change in this patch is that 'tempnam()' is used rather than 'tmpnam()' - 'tmpnam' creates a temp file on the root of the current drive, and if this is readonly would explain the 'freopen' errors occasionally reported. 'tempnam' creates the temp file in the %TEMP% directory. I've tested this when Python is installed by an admin, but the person installing the extension does *not* have admin permissions. Assuming the user has write permissions into the Python directory, this works correctly. As usual, assigning to Thomas for comment/review. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-07-03 09:54 Message: Logged In: YES user_id=14198 Yes, pywin32-202 is built with this. Checking in install.c; new revision: 1.6; previous revision: 1.5 Thanks! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-03 05:34 Message: Logged In: YES user_id=11105 I have read but not tested your patch. Except that I assume pywin32 build 202 installer already uses it, and it installed fine for me. It would be great if you check this in, probably these related old bugs can also be closed then: http://www.python.org/sf/555810 http://www.python.org/sf/555812 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983775&group_id=5470 From noreply at sourceforge.net Fri Jul 2 21:11:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 21:11:06 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 11:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-02 18:11 Message: Logged In: YES user_id=357491 You're right on the self.__stderr assignment snafu; typo from when I did the last change to move exc_info to the class instead of the instance. I hate running the Mnet test suite to trigger the bug since it is long and is a major resource hog. Fixed the bug, though, and ran the testing suite; looks good. Here is a sample output: Exception in thread The Asyncore Poller (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 442, in __bootstrap File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 422, in run File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py", line 133, in _asyncoreloop File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py", line 59, in write exceptions.TypeError: 'NoneType' object is not callable As you will notice the output isn't exactly standard (extra warning about how exception could have come about and the addition of "exceptions" for the listing of what the exception was), but nothing glaring. Is it even worth trying to ditch the appending of "exception"? It would be another thing to store in the class (types.ClassType if I follow traceback.py). I also took your advice and ripped out the traceback use. So now the class stores a reference to _sys.exc_info and the instance stores a ref to _sys.stderr . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-01 20:04 Message: Logged In: YES user_id=31435 Brett, it looks like self.__stderr is never given a value -- the __init__ code here binds a *local* vrbl __stderr to _sys.stderr. If so, that tells me the bulk of the patch hasn't actually been exercised (else it would have raised AttributeError trying to print to self.__stderr). To simplify it more, I think it would be fine to ignore sys.tracebacklimit. A Google search shows that virtually the only use of sys.tracebacklimit in real life is the use made of it here: passively accessing its value to simulate what it would have done if anyone had ever bothered to set it (of which I couldn't find even one example). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-30 21:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 21:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Fri Jul 2 22:27:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 22:28:02 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 14:43 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Brett Cannon (bcannon) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-02 22:27 Message: Logged In: YES user_id=31435 IMO, this is such a huge improvement over the status quo that it's not worth worrying about niggling format differences between this output and "the usual" traceback output. The *information* is the important thing, and this patch is the difference between no info and all the info there is. Check it in! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 21:11 Message: Logged In: YES user_id=357491 You're right on the self.__stderr assignment snafu; typo from when I did the last change to move exc_info to the class instead of the instance. I hate running the Mnet test suite to trigger the bug since it is long and is a major resource hog. Fixed the bug, though, and ran the testing suite; looks good. Here is a sample output: Exception in thread The Asyncore Poller (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 442, in __bootstrap File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 422, in run File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py", line 133, in _asyncoreloop File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py", line 59, in write exceptions.TypeError: 'NoneType' object is not callable As you will notice the output isn't exactly standard (extra warning about how exception could have come about and the addition of "exceptions" for the listing of what the exception was), but nothing glaring. Is it even worth trying to ditch the appending of "exception"? It would be another thing to store in the class (types.ClassType if I follow traceback.py). I also took your advice and ripped out the traceback use. So now the class stores a reference to _sys.exc_info and the instance stores a ref to _sys.stderr . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-01 23:04 Message: Logged In: YES user_id=31435 Brett, it looks like self.__stderr is never given a value -- the __init__ code here binds a *local* vrbl __stderr to _sys.stderr. If so, that tells me the bulk of the patch hasn't actually been exercised (else it would have raised AttributeError trying to print to self.__stderr). To simplify it more, I think it would be fine to ignore sys.tracebacklimit. A Google search shows that virtually the only use of sys.tracebacklimit in real life is the use made of it here: passively accessing its value to simulate what it would have done if anyone had ever bothered to set it (of which I couldn't find even one example). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-01 00:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-17 00:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Fri Jul 2 23:56:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 2 23:56:40 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 11:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-02 20:56 Message: Logged In: YES user_id=357491 In as rev. 1.42 (and two commits to Misc/NEWS; pain to explain this thing clearly). Do you think this should be backported? It should apply cleanly, but it does add a class and instance attribute, so the answer doesn't seem obvious to me. I say "yes", though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-02 19:27 Message: Logged In: YES user_id=31435 IMO, this is such a huge improvement over the status quo that it's not worth worrying about niggling format differences between this output and "the usual" traceback output. The *information* is the important thing, and this patch is the difference between no info and all the info there is. Check it in! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 18:11 Message: Logged In: YES user_id=357491 You're right on the self.__stderr assignment snafu; typo from when I did the last change to move exc_info to the class instead of the instance. I hate running the Mnet test suite to trigger the bug since it is long and is a major resource hog. Fixed the bug, though, and ran the testing suite; looks good. Here is a sample output: Exception in thread The Asyncore Poller (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 442, in __bootstrap File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 422, in run File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py", line 133, in _asyncoreloop File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py", line 59, in write exceptions.TypeError: 'NoneType' object is not callable As you will notice the output isn't exactly standard (extra warning about how exception could have come about and the addition of "exceptions" for the listing of what the exception was), but nothing glaring. Is it even worth trying to ditch the appending of "exception"? It would be another thing to store in the class (types.ClassType if I follow traceback.py). I also took your advice and ripped out the traceback use. So now the class stores a reference to _sys.exc_info and the instance stores a ref to _sys.stderr . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-01 20:04 Message: Logged In: YES user_id=31435 Brett, it looks like self.__stderr is never given a value -- the __init__ code here binds a *local* vrbl __stderr to _sys.stderr. If so, that tells me the bulk of the patch hasn't actually been exercised (else it would have raised AttributeError trying to print to self.__stderr). To simplify it more, I think it would be fine to ignore sys.tracebacklimit. A Google search shows that virtually the only use of sys.tracebacklimit in real life is the use made of it here: passively accessing its value to simulate what it would have done if anyone had ever bothered to set it (of which I couldn't find even one example). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-30 21:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 21:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Sat Jul 3 00:07:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 3 00:07:49 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 14:43 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-03 00:07 Message: Logged In: YES user_id=31435 I never care about old versions of Python, and 2.3 is ancient to me now . But the lack of sane error messages when threads are dying is certainly a serious bug, and this is certainly a bugfix -- it's a fine candidate for backporting. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 23:56 Message: Logged In: YES user_id=357491 In as rev. 1.42 (and two commits to Misc/NEWS; pain to explain this thing clearly). Do you think this should be backported? It should apply cleanly, but it does add a class and instance attribute, so the answer doesn't seem obvious to me. I say "yes", though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-02 22:27 Message: Logged In: YES user_id=31435 IMO, this is such a huge improvement over the status quo that it's not worth worrying about niggling format differences between this output and "the usual" traceback output. The *information* is the important thing, and this patch is the difference between no info and all the info there is. Check it in! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 21:11 Message: Logged In: YES user_id=357491 You're right on the self.__stderr assignment snafu; typo from when I did the last change to move exc_info to the class instead of the instance. I hate running the Mnet test suite to trigger the bug since it is long and is a major resource hog. Fixed the bug, though, and ran the testing suite; looks good. Here is a sample output: Exception in thread The Asyncore Poller (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 442, in __bootstrap File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 422, in run File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py", line 133, in _asyncoreloop File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py", line 59, in write exceptions.TypeError: 'NoneType' object is not callable As you will notice the output isn't exactly standard (extra warning about how exception could have come about and the addition of "exceptions" for the listing of what the exception was), but nothing glaring. Is it even worth trying to ditch the appending of "exception"? It would be another thing to store in the class (types.ClassType if I follow traceback.py). I also took your advice and ripped out the traceback use. So now the class stores a reference to _sys.exc_info and the instance stores a ref to _sys.stderr . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-01 23:04 Message: Logged In: YES user_id=31435 Brett, it looks like self.__stderr is never given a value -- the __init__ code here binds a *local* vrbl __stderr to _sys.stderr. If so, that tells me the bulk of the patch hasn't actually been exercised (else it would have raised AttributeError trying to print to self.__stderr). To simplify it more, I think it would be fine to ignore sys.tracebacklimit. A Google search shows that virtually the only use of sys.tracebacklimit in real life is the use made of it here: passively accessing its value to simulate what it would have done if anyone had ever bothered to set it (of which I couldn't find even one example). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-01 00:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-17 00:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Sat Jul 3 01:55:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 3 01:55:05 2004 Subject: [Patches] [ python-Patches-984492 ] Address bug 980938, add set_debug_output() function Message-ID: Patches item #984492, was opened at 2004-07-02 22: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=984492&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Lamanna (jmlamanna) Assigned to: Nobody/Anonymous (nobody) Summary: Address bug 980938, add set_debug_output() function Initial Comment: Added a set_debug_output() function to smtp.SMTP All debugging output had been previously going to stdout by default. This allows any file to be set as the debug output. It defaults to sys.stderr. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984492&group_id=5470 From noreply at sourceforge.net Sat Jul 3 02:02:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 3 02:02:47 2004 Subject: [Patches] [ python-Patches-984495 ] Fix bug 982806 - allow for optional 2nd argument Message-ID: Patches item #984495, was opened at 2004-07-02 23: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=984495&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Lamanna (jmlamanna) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bug 982806 - allow for optional 2nd argument Initial Comment: Typo in setting the default value of the flags in the gdbm module, which causes open() to fail if no second argument is given. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984495&group_id=5470 From noreply at sourceforge.net Sat Jul 3 12:15:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 3 12:15:12 2004 Subject: [Patches] [ python-Patches-984654 ] socket module does not support AF_NETLINK Message-ID: Patches item #984654, was opened at 2004-07-03 16:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket module does not support AF_NETLINK Initial Comment: [forwarded from http://bugs.debian.org/257444] The socket module is missing the AF_NETLINK constant and the associated support, as well as a whole bunch of others. The list of missing address families seems to be: #define AF_ATMPVC 8 /* ATM PVCs */ #define AF_DECnet 12 /* Reserved for DECnet project */ #define AF_NETBEUI 13 /* Reserved for 802.2LLC project*/ #define AF_SECURITY 14 /* Security callback pseudo AF */ #define AF_KEY 15 /* PF_KEY key management API */ #define AF_NETLINK 16 #define AF_ROUTE AF_NETLINK /* Alias to emulate 4.4BSD */ #define AF_ASH 18 /* Ash */ #define AF_ECONET 19 /* Acorn Econet */ #define AF_ATMSVC 20 /* ATM SVCs */ #define AF_SNA 22 /* Linux SNA Project (nutters!) */ #define AF_IRDA 23 /* IRDA sockets */ #define AF_PPPOX 24 /* PPPoX sockets */ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 From noreply at sourceforge.net Sat Jul 3 13:37:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 3 13:37:05 2004 Subject: [Patches] [ python-Patches-984672 ] Fix bug 982806 - allow for optional 2nd argument Message-ID: Patches item #984672, was opened at 2004-07-03 10:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984672&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Lamanna (jmlamanna) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bug 982806 - allow for optional 2nd argument Initial Comment: Typo in setting the default value of the flags in the gdbm module, which causes open() to fail if no second argument is given. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984672&group_id=5470 From noreply at sourceforge.net Sat Jul 3 16:00:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 3 16:00:19 2004 Subject: [Patches] [ python-Patches-954922 ] Fix for 754449: hiding exc in threading during interp shutdn Message-ID: Patches item #954922, was opened at 2004-05-16 11:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Fix for 754449: hiding exc in threading during interp shutdn Initial Comment: Decided to start a fresh tracker item for this patch since I already attempted to close bug 754449 once before and I want to make sure the two fixes stay separate. Someone emailed me a program whose testing suite could reliably reproduce the problem as reported in the bug report (for a quck refresher, basically if someone leaves a threading.Thread instance running while the interpreter is being shutdown and an exception is raised in the thread then that exception will cause *another* exception in the subsequent attempt to report the exception from the thread because all globals have been set to None at that point). The previous fix that I checked in turned out not to be thorough enough (still needed, though). I am currently waiting for the person who emailed me the triggering code to let me know if I can publish how to cause the error. Attached is a patch to remove all instances of accessing globals (just as if I was writing a __del__ method for threading.Thread) by storing copies of sys.stderr, sys.exc_info, and sys.tracebacklimit. All of this is so that a decent approximation of a traceback print- out can occur without having to call the 'traceback' module since its functions depend a lot on each other. I mainly need someone else who is more familiar with dealing with tracebacks to make sure that I have not done something stupid and to make sure this is the best way to handle things. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-03 13:00 Message: Logged In: YES user_id=357491 Rev. 1.38.6.1 has the patch along with a backport of rev. 1.41 from HEAD (my first attempt at this that fell short). Thanks for the help on this, Tim. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-02 21:07 Message: Logged In: YES user_id=31435 I never care about old versions of Python, and 2.3 is ancient to me now . But the lack of sane error messages when threads are dying is certainly a serious bug, and this is certainly a bugfix -- it's a fine candidate for backporting. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 20:56 Message: Logged In: YES user_id=357491 In as rev. 1.42 (and two commits to Misc/NEWS; pain to explain this thing clearly). Do you think this should be backported? It should apply cleanly, but it does add a class and instance attribute, so the answer doesn't seem obvious to me. I say "yes", though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-02 19:27 Message: Logged In: YES user_id=31435 IMO, this is such a huge improvement over the status quo that it's not worth worrying about niggling format differences between this output and "the usual" traceback output. The *information* is the important thing, and this patch is the difference between no info and all the info there is. Check it in! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 18:11 Message: Logged In: YES user_id=357491 You're right on the self.__stderr assignment snafu; typo from when I did the last change to move exc_info to the class instead of the instance. I hate running the Mnet test suite to trigger the bug since it is long and is a major resource hog. Fixed the bug, though, and ran the testing suite; looks good. Here is a sample output: Exception in thread The Asyncore Poller (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 442, in __bootstrap File "/Users/drifty/Code/compiled_CVS/lib/python2.4/threading.py", line 422, in run File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/Asyncore.py", line 133, in _asyncoreloop File "/Users/drifty/Code/Python/mnet/repos/mnet/pyutil/debugprint.py", line 59, in write exceptions.TypeError: 'NoneType' object is not callable As you will notice the output isn't exactly standard (extra warning about how exception could have come about and the addition of "exceptions" for the listing of what the exception was), but nothing glaring. Is it even worth trying to ditch the appending of "exception"? It would be another thing to store in the class (types.ClassType if I follow traceback.py). I also took your advice and ripped out the traceback use. So now the class stores a reference to _sys.exc_info and the instance stores a ref to _sys.stderr . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-01 20:04 Message: Logged In: YES user_id=31435 Brett, it looks like self.__stderr is never given a value -- the __init__ code here binds a *local* vrbl __stderr to _sys.stderr. If so, that tells me the bulk of the patch hasn't actually been exercised (else it would have raised AttributeError trying to print to self.__stderr). To simplify it more, I think it would be fine to ignore sys.tracebacklimit. A Google search shows that virtually the only use of sys.tracebacklimit in real life is the use made of it here: passively accessing its value to simulate what it would have done if anyone had ever bothered to set it (of which I couldn't find even one example). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-30 21:33 Message: Logged In: YES user_id=357491 Uploading a new version of the patch to store one of the variables in the class instead of the instance since it it never expected to change. Also changed the comment. Still waiting for someone else to take a look at this code before I check it in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 21:37 Message: Logged In: YES user_id=357491 Just posted how to reproduce the bug using the in-dev version of mnet as a post to the bug tracker item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=954922&group_id=5470 From noreply at sourceforge.net Sun Jul 4 07:24:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 4 07:27:39 2004 Subject: [Patches] [ python-Patches-968063 ] Add fileinput.islastline() Message-ID: Patches item #968063, was opened at 2004-06-07 09:45 Message generated for change (Comment added) made by dharriso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Relm Arrowny (relm) Assigned to: Nobody/Anonymous (nobody) Summary: Add fileinput.islastline() Initial Comment: You can test for the first line of a file with fileinput.isfirstline(), but there is no corresponding fileinput.islastline() to test for the last line of a file. Note that there is already an unapplied patch for this at request ID 776100, but it is faulty in that it only tests for end of buffer and not end of file. I was not sure how to append this patch to the existing request, so have started a new one. Hope this is okay. This patch also includes documentation and test updates. ---------------------------------------------------------------------- Comment By: Dave Harrison (dharriso) Date: 2004-07-04 11:24 Message: Logged In: YES user_id=1076674 I would say that I'm -0.5 on this feature. After looking over the current code for fileinput.py in the cvs tree, it looks like the current code implements an iterator model. Since fileinput.py uses the next() call to move along its input, and raises StopIteration if there are no more lines to be returned, this function would have to be polled to find out if the final line had been reached - where a try/except block that caught StopIteration would seem more intuitive to me (Inkeeping with the current code). However it might be considered that the nextfile() function be changed to raise StopIteration after the last file had been completed to maintain consistency between the lines and files aspects of the class. ---------------------------------------------------------------------- Comment By: Relm Arrowny (relm) Date: 2004-06-15 18:42 Message: Logged In: YES user_id=1058331 The OP's use case was too simplified to convey the usefulness of fileinput.islastline(). It does not just save a couple of lines. I am attaching a "wc" or "word count" program to demonstrate. Note the following problems with the current work-around: 1. Instead of doing end-of-file processing at the end of a file, we must do it at the beginning of the *next* file. 2. Useful functions such as fileinput.filelineno() and fileinput.filename() now refer to the *wrong* file, so now we need to manually keep track of these values ourselves. 3. Perhaps a minor point, but this work-around only works at the *beginning* of the loop instead of the end. It feels somewhat awkward. 4. End-of-file processing must occur both in the loop and once outside. A function avoids code duplication, but to refer to variables in the loop, they must be passed into and out of the function (6 in, 2 out for the "wc" example... maybe keyword arguments would have helped). 5. Most important is readablility. It's not obvious that `fileinput.isfirstline() and fileinput.lineno() != 1` means we are the end of the (previous!) file. Using `fileinput.islastline()` would be much clearer. And not that it is a reason, but Perl and Ruby solve this with an `eof` function and `eof?` method, respectively. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-15 12:05 Message: Logged In: YES user_id=80475 I'm -0 on complicating this venerable interface. Also, I find it unnatural for the inside of a loop to be able to ascertain whether it is in its final iteration. The closest approximation is the for-else clause which is vary rarely used in normal python programming. While the OP was able to sketch a use case, it involved only saving a couple of lines over what can be done with the existing API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 From noreply at sourceforge.net Sun Jul 4 07:57:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 4 07:57:42 2004 Subject: [Patches] [ python-Patches-984880 ] fix regression on 2.3 branch: Lib/threading Message-ID: Patches item #984880, was opened at 2004-07-04 11:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&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: fix regression on 2.3 branch: Lib/threading Initial Comment: introduced by the recent backport: --- Lib/threading.py~ 2004-07-04 13:22:13.000000000 +0200 +++ Lib/threading.py 2004-07-04 13:55:57.000000000 +0200 @@ -10,7 +10,7 @@ from StringIO import StringIO as _StringIO from time import time as _time, sleep as _sleep -from traceback import print_exc as _print_exc +from traceback import format_exc as _format_exc # Rename some stuff so "from threading import *" is safe __all__ = ['activeCount', 'Condition', 'currentThread', 'enumerate', 'Event', ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 From noreply at sourceforge.net Sun Jul 4 07:57:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 4 07:57:55 2004 Subject: [Patches] [ python-Patches-984880 ] fix regression on 2.3 branch: Lib/threading Message-ID: Patches item #984880, was opened at 2004-07-04 11:57 Message generated for change (Settings changed) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 8 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: fix regression on 2.3 branch: Lib/threading Initial Comment: introduced by the recent backport: --- Lib/threading.py~ 2004-07-04 13:22:13.000000000 +0200 +++ Lib/threading.py 2004-07-04 13:55:57.000000000 +0200 @@ -10,7 +10,7 @@ from StringIO import StringIO as _StringIO from time import time as _time, sleep as _sleep -from traceback import print_exc as _print_exc +from traceback import format_exc as _format_exc # Rename some stuff so "from threading import *" is safe __all__ = ['activeCount', 'Condition', 'currentThread', 'enumerate', 'Event', ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 From noreply at sourceforge.net Sun Jul 4 08:11:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 4 08:11:36 2004 Subject: [Patches] [ python-Patches-984880 ] fix regression on 2.3 branch: Lib/threading Message-ID: Patches item #984880, was opened at 2004-07-04 11:57 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: fix regression on 2.3 branch: Lib/threading Initial Comment: introduced by the recent backport: --- Lib/threading.py~ 2004-07-04 13:22:13.000000000 +0200 +++ Lib/threading.py 2004-07-04 13:55:57.000000000 +0200 @@ -10,7 +10,7 @@ from StringIO import StringIO as _StringIO from time import time as _time, sleep as _sleep -from traceback import print_exc as _print_exc +from traceback import format_exc as _format_exc # Rename some stuff so "from threading import *" is safe __all__ = ['activeCount', 'Condition', 'currentThread', 'enumerate', 'Event', ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2004-07-04 12:11 Message: Logged In: YES user_id=60903 complete patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 From noreply at sourceforge.net Sun Jul 4 08:21:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 4 08:21:45 2004 Subject: [Patches] [ python-Patches-984880 ] fix regression on 2.3 branch: Lib/threading Message-ID: Patches item #984880, was opened at 2004-07-04 12:57 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Matthias Klose (doko) >Assigned to: Brett Cannon (bcannon) Summary: fix regression on 2.3 branch: Lib/threading Initial Comment: introduced by the recent backport: --- Lib/threading.py~ 2004-07-04 13:22:13.000000000 +0200 +++ Lib/threading.py 2004-07-04 13:55:57.000000000 +0200 @@ -10,7 +10,7 @@ from StringIO import StringIO as _StringIO from time import time as _time, sleep as _sleep -from traceback import print_exc as _print_exc +from traceback import format_exc as _format_exc # Rename some stuff so "from threading import *" is safe __all__ = ['activeCount', 'Condition', 'currentThread', 'enumerate', 'Event', ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2004-07-04 13:11 Message: Logged In: YES user_id=60903 complete patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 From noreply at sourceforge.net Sun Jul 4 14:40:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 4 14:40:51 2004 Subject: [Patches] [ python-Patches-984880 ] fix regression on 2.3 branch: Lib/threading Message-ID: Patches item #984880, was opened at 2004-07-04 04:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: fix regression on 2.3 branch: Lib/threading Initial Comment: introduced by the recent backport: --- Lib/threading.py~ 2004-07-04 13:22:13.000000000 +0200 +++ Lib/threading.py 2004-07-04 13:55:57.000000000 +0200 @@ -10,7 +10,7 @@ from StringIO import StringIO as _StringIO from time import time as _time, sleep as _sleep -from traceback import print_exc as _print_exc +from traceback import format_exc as _format_exc # Rename some stuff so "from threading import *" is safe __all__ = ['activeCount', 'Condition', 'currentThread', 'enumerate', 'Event', ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-04 11:40 Message: Logged In: YES user_id=357491 Unfortunately, Matthias, it isn't quite that simple. traceback.format_exc was introduced in Python 2.4, so obviously that won't work. But traceback.print_exc does work. I just reworked the line that used format_exc into two lines; one printing out the filename, and another just using print_exc to call sys.stderr. So it's all fixed (and tested; fix for 2.3 and the original in 2.4 =). Don't know why the diff didn't pick up the format_exc import. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2004-07-04 05:11 Message: Logged In: YES user_id=60903 complete patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984880&group_id=5470 From gamecity at nettaxi.com Mon Jul 5 12:03:06 2004 From: gamecity at nettaxi.com (Accessing H. Kidnapers) Date: Mon Jul 5 12:03:26 2004 Subject: [Patches] Read:_Best offer of this year ;) Message-ID: <4214014100.20040705110306@nettaxi.com> >Ester Lorraine Burt Roxie Oliver Carter Lupe Charlene Sensation!! We opened a NEW site with unbeatable prices and products. 800 WORLD BEST software with 90% discount - that is a really BEST offer just imagine, you can buy ALL software that you ever need and pay price of just one of it! Office 2003 for 50$ - nice deal right ? ;) retail price is 700$ - great savings, huh? Please spend few moments of yours precious time to check our offer - it is more than worth it! http://Evangeline.1500-programs.biz/?Maynard >If you've enjoyed a little and endured a lot, you've really done pretty well. >All great men are gifted with intuition. They know without reasoning or analysis, what they need to know. >All that we see or seem, is but a dream within a dream. >Never celebrate until you are really out of the woods. They might be behind the last tree. >We are no longer puppets being manipulated by outside powerful forces: we become the powerful force ourselves. >Laziness never arrived at the attainment of a good wish. >I count life just a stuff to try the soul's strength on. >It is not miserable to be blind it is miserable to be incapable of enduring blindness. >Chance happens to all, but to turn chance to account is the gift of few. >The pleasure of reading is doubled when one lives with another who shares the same books. >How many feasible projects have miscarried through despondency, and been strangled in their birth by a cowardly imagination. >The torpid artist seeks inspiration at any cost, by virtue or by vice, by friend or by fiend, by prayer or by wine. >Celebrate what you want to see more of. >Whenever we confront an unbridled desire we are surely in the presence of a tragedy-in-the-making. >Every man must do two things alone he must do his own believing and his own dying. >You shall judge a man by his foes as well as by his friends. >I swear to the Lord, I still can't see, why Democracy means, everybody but me. >He that complies against his will is of his own opinion still. >Action is the real measure of intelligence. From Rosanne at roxette.org Tue Jul 6 06:40:20 2004 From: Rosanne at roxette.org (Rosanne@roxette.org) Date: Mon Jul 5 14:42:34 2004 Subject: [Patches] dirty father-daughter sex.. diabetes Message-ID: <88268pf35yl30pe$52zw40r0y98$890up07rq@whish.nctta.org> >Great minds think alike >Share and share alike! Hot and sexy moms! Experienced mature women are teaching their sons fucking! Incredibly dirty incest collection mom and son fucking! She was drunk and saw her young son undressing before going to sleep She imagined his firm hard dick, and decided to play a naughty game Let s check your dicky, my sweet little boy! Yep, you ve already grown up, darling, to have sex with your loving mommy! http://feudal.shockingincest.info/milk-incest/ >A constant guest is never welcome. >To give subtilty to the simple, to the young man knowledge and discretion. From noreply at sourceforge.net Tue Jul 6 04:24:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 04:45:53 2004 Subject: [Patches] [ python-Patches-980475 ] partially initialized heap allocated type objects Message-ID: Patches item #980475, was opened at 2004-06-26 16:47 Message generated for change (Settings changed) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: partially initialized heap allocated type objects Initial Comment: There is a problem if you try to dealloc a partially initialized heap allocated type object. Because PyObject_GC_TRACK is not typically called until initialization is done, the gc_refs value is set to GC_UNTRACKED. In type_dealloc, it calls _PyObject_GC_UNTRACK which skips the check to see if it is GC_UNTRACKED. This patch fixes it so that it calls PyObject_GC_UnTrack to correctly handle this case. ---------------------------------------------------------------------- >Comment By: Eric Huss (ehuss) Date: 2004-07-05 19:24 Message: Logged In: YES user_id=393416 To be honest, I didn't realize that _PyObject_GC_TRACK was being called in PyType_GenericAlloc in the type_new() function. It was a problem with my code trying to make type objects. Just have to remember to call gc_track early on. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-05 15:26 Message: Logged In: YES user_id=31435 Well, it's not intended that type_dealloc be robust against insane objects. If you leave type->tp_base (etc, etc) in an insane (or uninitialized) state, type_dealloc may blow up too, or lead to arbitrary memory corruption. Why is the gc tracking status special? One way it's special is that it's a place we *can* stick a useful assert to warn you when you're passing an insane object to type_dealloc -- explicitly initializing the gc_refs member to the untracked state is one of the few pieces of initialization done by the gc malloc functions. The patch would disable that sanity check, so is unattractive on that count. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470 From noreply at sourceforge.net Tue Jul 6 00:26:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 04:45:54 2004 Subject: [Patches] [ python-Patches-980475 ] partially initialized heap allocated type objects Message-ID: Patches item #980475, was opened at 2004-06-26 19:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: partially initialized heap allocated type objects Initial Comment: There is a problem if you try to dealloc a partially initialized heap allocated type object. Because PyObject_GC_TRACK is not typically called until initialization is done, the gc_refs value is set to GC_UNTRACKED. In type_dealloc, it calls _PyObject_GC_UNTRACK which skips the check to see if it is GC_UNTRACKED. This patch fixes it so that it calls PyObject_GC_UnTrack to correctly handle this case. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-05 18:26 Message: Logged In: YES user_id=31435 Well, it's not intended that type_dealloc be robust against insane objects. If you leave type->tp_base (etc, etc) in an insane (or uninitialized) state, type_dealloc may blow up too, or lead to arbitrary memory corruption. Why is the gc tracking status special? One way it's special is that it's a place we *can* stick a useful assert to warn you when you're passing an insane object to type_dealloc -- explicitly initializing the gc_refs member to the untracked state is one of the few pieces of initialization done by the gc malloc functions. The patch would disable that sanity check, so is unattractive on that count. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470 From noreply at sourceforge.net Tue Jul 6 06:37:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 06:37:09 2004 Subject: [Patches] [ python-Patches-985713 ] bug skipping optional keyword arguments of type "w#" Message-ID: Patches item #985713, was opened at 2004-07-05 23:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: bug skipping optional keyword arguments of type "w#" Initial Comment: When using PyArg_ParseTupleAndKeywords(), if you use "w#" as an optional keyword argument, you cannot skip it and still specify an optional argument that follows it. For example, take the following function: static PyObject * dummy_func(PyObject *self, PyObject *args, PyObject *kwds) { char *string; char *buf = NULL; int bufsize = 0; unsigned short ushort = 5; static char *kwlist[] = { "string", "buffer", "ushort", NULL }; if (! PyArg_ParseTupleAndKeywords(args, kwds, "s|w#H", kwlist, &string, &buf, &bufsize, &ushort)) return NULL; printf("buf=%p, bufsize=%d, ushort=%hu\n", buf, bufsize, ushort); snprintf(buf, bufsize, "you said \%s\\n", hostname); return Py_BuildValue("s", hostname); } You can call this function successfully as follows: # don't specify buffer or ushort dummy_func("text") Or like this: # specify buffer buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf) Or like this: # specify buffer and ushort buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf, ushort=10) However, the following does NOT work: # specify ushort without first specifying buffer dummy_func("text", ushort=10) It fails with the following error: Traceback (most recent call last): File "", line 1, in ? TypeError: argument 2 impossible This is because the skipitem() function in Python/getargs.c does not know how to skip arguments for the "w#" format unit. I've attached a patch that fixes this. Note that skipitem() is also missing code for many other legal format units, in addition to "w" and "w#". In particular: u, u# (see patch #853890) es, es# et, et# I (capital i) k K D S U t# (tuple) It might be a good idea to refactor the code so that if/when new format units are added, the same code will handle them for both skipitem() and convertsimple(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 From noreply at sourceforge.net Tue Jul 6 06:39:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 06:39:12 2004 Subject: [Patches] [ python-Patches-853890 ] Optional keyword unicode args not handled correctly Message-ID: Patches item #853890, was opened at 2003-12-04 02:05 Message generated for change (Comment added) made by mdr0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853890&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Optional keyword unicode args not handled correctly Initial Comment: Added a case for 'u' in skipitem in getargs.c ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-07-05 23:39 Message: Logged In: YES user_id=994239 skipitem() is actually missing code for a number of other format units, in addition to "u" and "u#". See patch 985713 for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853890&group_id=5470 From noreply at sourceforge.net Tue Jul 6 06:42:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 06:42:20 2004 Subject: [Patches] [ python-Patches-985713 ] bug skipping optional keyword arguments of type "w#" Message-ID: Patches item #985713, was opened at 2004-07-05 23:37 Message generated for change (Comment added) made by mdr0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: bug skipping optional keyword arguments of type "w#" Initial Comment: When using PyArg_ParseTupleAndKeywords(), if you use "w#" as an optional keyword argument, you cannot skip it and still specify an optional argument that follows it. For example, take the following function: static PyObject * dummy_func(PyObject *self, PyObject *args, PyObject *kwds) { char *string; char *buf = NULL; int bufsize = 0; unsigned short ushort = 5; static char *kwlist[] = { "string", "buffer", "ushort", NULL }; if (! PyArg_ParseTupleAndKeywords(args, kwds, "s|w#H", kwlist, &string, &buf, &bufsize, &ushort)) return NULL; printf("buf=%p, bufsize=%d, ushort=%hu\n", buf, bufsize, ushort); snprintf(buf, bufsize, "you said \%s\\n", hostname); return Py_BuildValue("s", hostname); } You can call this function successfully as follows: # don't specify buffer or ushort dummy_func("text") Or like this: # specify buffer buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf) Or like this: # specify buffer and ushort buf = array.array('c', [' ' for x in range(0, 1023)]) dummy_func("text", buffer=buf, ushort=10) However, the following does NOT work: # specify ushort without first specifying buffer dummy_func("text", ushort=10) It fails with the following error: Traceback (most recent call last): File "", line 1, in ? TypeError: argument 2 impossible This is because the skipitem() function in Python/getargs.c does not know how to skip arguments for the "w#" format unit. I've attached a patch that fixes this. Note that skipitem() is also missing code for many other legal format units, in addition to "w" and "w#". In particular: u, u# (see patch #853890) es, es# et, et# I (capital i) k K D S U t# (tuple) It might be a good idea to refactor the code so that if/when new format units are added, the same code will handle them for both skipitem() and convertsimple(). ---------------------------------------------------------------------- >Comment By: Mark D. Roth (mdr0) Date: 2004-07-05 23:42 Message: Logged In: YES user_id=994239 Whoops! You'll need to change "hostname" to "string" in that example function. I missed a few occurances of that variable when I renamed it to make the example more clear... *sheepish grin* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=985713&group_id=5470 From BarryWinkler at adsrealestate.com Tue Jul 6 09:28:15 2004 From: BarryWinkler at adsrealestate.com (Marian Montgomery) Date: Tue Jul 6 08:24:35 2004 Subject: [Patches] Top of the line software, Bargain basement prices Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040706/9cab15cd/attachment.htm From noreply at sourceforge.net Tue Jul 6 16:28:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 16:28:41 2004 Subject: [Patches] [ python-Patches-986010 ] add missing doc for datetime C API Message-ID: Patches item #986010, was opened at 2004-07-06 08:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: add missing doc for datetime C API Initial Comment: Attached is the missing documentation for the accessor macros. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 From noreply at sourceforge.net Tue Jul 6 16:38:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 16:38:25 2004 Subject: [Patches] [ python-Patches-986010 ] add missing doc for datetime C API Message-ID: Patches item #986010, was opened at 2004-07-06 08:28 Message generated for change (Settings changed) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Tim Peters (tim_one) Summary: add missing doc for datetime C API Initial Comment: Attached is the missing documentation for the accessor macros. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 From noreply at sourceforge.net Tue Jul 6 16:39:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 16:39:44 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-07-06 08:39 Message: Logged In: YES user_id=619560 The additional changes to the documentation are available in patch 986010. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-23 12:29 Message: Logged In: YES user_id=31435 Good eye! Yes, the accessor macros should be documented too, and it would be great if you whipped up a patch for that. This report has already been closed, so best to open a new patch report for it. You can assign the report to me and I'll make time to get it checked in. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-22 11:06 Message: Logged In: YES user_id=619560 Yes, this has been a long time coming. Collaboration by e-mail with people working on completely different projects can be quite a challenge! Thanks for getting this checked in. When 2.4a1 comes out I will be providing a new version of cx_Oracle that takes advantage of these functions. I just noticed that I missed the macros that are defined in datetime.h that were not modified with my patch -- specifically those used to acquire the components of the date/time objects. Should those be documented as well? I'm assuming the answer is yes -- so would it be helpful if I did so and attached a patch to this set of patches or do I need to create a new patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-20 16:51 Message: Logged In: YES user_id=31435 Thanks for your patience, Anthony! I checked this in after minor fiddling. Biggest change was to supply a new macro and docs, to expose the unreferenced Delta_FromDelta member of the C API struct. I do wish we had test cases -- as is, these maros could be totally busted and we'd have no way to know that. But virtually all of the C API is untested that way, so it's not a fatal objection. Doc/api/concrete.tex; new revision: 1.45 Include/datetime.h; new revision: 1.5 Misc/ACKS; new revision: 1.267 Misc/NEWS; new revision: 1.1008 Modules/datetimemodule.c; new revision: 1.74 The answers to your questions are implicit in what I checked in . Note that in 2.4, datetimemodule.c *is* compiled as part of the core. Guido nevertheless didn't want the datetime API to take advantage of that (I'm unclear on why). I'm content to document the macros and leave it at that. The DB API functions don't bother me one way or the other, so left them in. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-14 09:23 Message: Logged In: YES user_id=619560 I have attached a patch for the documentation as requested. Not being certain of the format and requirements for the content, your comments are appreciated. I have a few questions that might help focus your comments. 1) Should the API structure be documented and users of datetime.h encouraged to use it directly? Or should it be "implementation details" and only those methods that I have provided should be available? To help answer this question, is it intended to ever bring datetime objects into the "core" rather than as a separate module? 2) The DB API helper functions are provided because Marc Andre Lemburg thought it would be a good idea. Please take a look and see if it makes sense now that it is documented. :-) Please review and give me your feedback. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-07 07:57 Message: Logged In: YES user_id=619560 Yes, the top two files are the ones involved. As per your suggestion I deleted the other four files to avoid further confusion. I understand the concern for documentation. I'll see what I can do to get at least a preliminary patch on that front ready this week. Earlier discussions suggested that the documentation reside solely in the include file but I think adding a section to the Python/C API documentation would make a lot more sense. Please stand by. :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:43 Message: Logged In: YES user_id=31435 Assuming the current state of the proposal consists of the first two patches on the list ("patch for datetimemodule.c" and "patch for datetime.h"), I'm probably happy to commit them. Can't say for sure right now, because SF CVS is dead, and can't get a current checkout to try them with. The one necessary thing I don't see are docs: how are users supposed to know this exists, let alone know how to use it? We need a new section for datetime objects in the Python/C API Reference Manual, in the Other Objects part of the Concrete Objects Layer section. You don't have to write LaTeX, plain text is fine. Look at the other sections in that chapter for what's needed (an overview, and a precise account of what's in the new C API and how to use it). Don't let that discourage you -- you're very close! If I don't force docs out of you now, docs will never get written. That's why I'm trying to force docs out of you now . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-05 17:10 Message: Logged In: YES user_id=31435 Heh. Just noticed there are 6 patches attached to this report. Are all of them part of the suggested change, or, if not, which are the current ones (if that's the case, the best way to answer the question is to delete the out-of-date patches)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-01 11:53 Message: Logged In: YES user_id=31435 I intend to do it this week, but have no time today or tomorrow. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-06-01 11:44 Message: Logged In: YES user_id=619560 Sure. What's the chance of it being reviewed prior to the release of Python 2.4 a1? I just saw the preannouncement today -- it is scheduled for the end of this month, I believe. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-31 21:12 Message: Logged In: YES user_id=31435 Assigned to me for the next review. Can't do it immediately, but will do my best to free up some time for it "soon". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 13:39 Message: Logged In: YES user_id=619560 I would agree with your assessment of the issue regarding the TimeFromTicks() API and find it quite reasonable. Either implement both at the C and Python levels or not at all. Since there is no consensus on this, none it is. :-) Did you have a chance to review the actual code? The changes are fairly minimal but you might have questions about readability, names, etc. It would be great if this could be included in an upcoming 2.4 alpha/beta so that I can provide support in cx_Oracle for the next release. Thanks for your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-26 13:32 Message: Logged In: YES user_id=31435 Under the belief that the *intent* of this patch is to add a C API to Python's datetime module, it should stick to exposing C ways to spell what Python programmers can already do from Python using datetime. Since nothing like TimeFromTicks() exists in the Python datetime API, it simply doesn't make sense to invent one available only from C. It *may* make sense to invent one in a DB API wrapper around datetime, but I view that as out of scope for this patch. I would not add TimeFromTicks() to the Python datetime API either, because the docs are ambiguous. The sample implementation Marc-Andre posted here uses localtime() to resolve the ambiguity in the docs, but that has to be a wrong choice for some time-of-day apps. For example, there's apparently no portable way to spell "noon" using TimeFromTicks(): the value you get back depends on which time zone localtime() happens to use at the time it's called. If people want time-of-day from a POSIX timestamp, it remains easy to get it from what datetime already supplies, but to do so you have to be explicit about whether you want UTC or local time interpretation. Both are easily spelled already, and it's a Good Thing that you need to be explicit if you want to do such a thing. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=38388 Thanks, but I don't have time to review it. As for the TimeFromTicks() API: I can understand that you don't feel like implementing it, but hey, I won't use datetime either. The only reason I'm trying to push full support of the DB API specs is that Guido et al. wanted to see a note in the DB API that datetime also provides a usable interface to do date/time interfacing. I'm not very interested in datetime myself, since I'll continue to use mxDateTime, so the situation for me is somewhat similar to yours: investing time into something that I myself will probably not use much (I will add support to mxODBC for those who like to use datetime instead of mxDateTime, but won't use it myself). Feel free to check in your changes. Thanks. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-26 10:30 Message: Logged In: YES user_id=619560 Attached are the modified patches based on your suggestions. I have tested them with my own module cx_Oracle and they appear to work correctly. Any further suggestions would be appreciated. I would like to see this included for Python 2.4 if at all possible. Please let me know what I need to do (if anything) to get this to happen. As for the TimeFromTicks() routine, Oracle has absolutely no use for a "time-only" data type and does not support it. It clearly does not have broad support so I really have no desire to implement it since I will never use it myself. If you consider it important, you could add it yourself or we could wait until someone else who requires it for their implementation of the DB API requires it. I'm not trying to be rude or trying to denigrate the DB API, simply trying to be practical. Please let me know if this is offensive in any way. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-19 02:28 Message: Logged In: YES user_id=38388 >From the DB API specs: TimeFromTicks(ticks) This function constructs an object holding a time value from the given ticks value (number of seconds since the epoch; see the documentation of the standard Python time module for details). The reason for this having this API is to be able to construct an object suitable for passing to the database given a Unix ticks value. Since the ticks value contains both a date and a time part and most databases have a special column type for time value, we need two constructor APIs, one to extract just the date part and one for the time part. Here's the mxDateTime implementation for reference: def TimeFromTicks(ticks, # Locals: DateTimeDelta=DateTimeDelta,localtime=_time.localtime): """ TimeFromTicks(ticks) Constructs a DateTimeDelta instance pointing to the local time indicated by the given ticks value. The date part is ignored. """ return apply(DateTimeDelta, (0,) + localtime(ticks)[3:6]) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-03 11:46 Message: Logged In: YES user_id=31435 I don't understand what TimeFromTicks() is supposed to do. Seconds-from-the-epoch is a point in time, not a time-of- day. If some DB API requires guessing some transformation from seconds-from-the-epoch to time-of-day, that's fine, but it doesn't belong in Python's datetime module. The datetime module should certainly have a method to construct a datetime.datetime from a seconds-from-the- epoch argument -- seconds-from-the-epoch is a way of specifying a datetime.datetime. Given that, if the intent is to throw away the datetime.date portion of the datetime.datetime object, retaining only the datetime.time portion, then that's trivially accomplished by invoking dt.time () (where dt is the datetime.datetime object). Do any databases really store time-of-day as a seconds-from- the-epoch value? Google's top hit on TimeFromTicks() today happens to be a msg from Anthony saying that Oracle does not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 11:24 Message: Logged In: YES user_id=38388 Macro: I don't know whether you need the macro or not (you probably do for the type checks). In any case, you can do without relying on Python providing you this information via the build process, since only datetimemodule.c is using the header file while Python is being built. TimeFromTicks(): I' ve stated my point. I don't think there's anything to add - I'm tired of fighting for these things... one of the reasons I stopped actively discussing things on python-dev. IMHO, a product that's aimed at developers should make things easy for the developer and try to avoid code duplication if possible. The API is needed in order to support database interfaces that use Unix ticks as basis for date/time, so if you don't add it to the module, the ten or twenty module authors out there will have to duplicate that piece of work in their implementation. Transition: This was already discussed on the db-api list. We love freedom of choice. Nothing to add. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 10:48 Message: Logged In: YES user_id=619560 About the Py_BUILD_CORE issue: You are suggesting that I define this in datetimemodule.c just prior to the include of datetime.h? Or are you suggesting some other macro? I am not sure about the comment about "not needing a macro in the first place" since there are two groups that will be importing datetime.h: the first being the datetime module itself and the second being the DB API modules. The macro is definitely required to distinguish between the two -- unless I am missing something? On the TimeFromTicks() issue: You obviously consider it important that the three methods be available at the C level for DB API module authors to use directly. My objection is simply a reiteration of an objection raised by Tim Peters. I think you'll have to argue that one with him. :-) I'll provide my implementations for cx_Oracle as part of the patches and then you can fight it out and I'll stay out of it. :-) As for the transition period, I assumed that with the introduction of a standard datetime module, that it would become the suggested implementation for database interfaace modules. That said, I don't really have any authority to say anything on this front so I'll leave that to you and others to decide. :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-03 09:26 Message: Logged In: YES user_id=38388 About the Py_BUILD_CORE issue: Sorry, I didn't know that Python does not define this macro for core modules. Nevertheless, looking at the datetime module code I don't really understand why you would need such a macro in the first place. Since the datetime module is the only code including the datetime.h header file it should be easy to add a macro definition just before importing datetime.h. On the TimeFromTicks() issue: The whole point of this discussion is to make the datetime module easily usable for authors of database modules. Since the DB API specifies that the module will need to export the three functions, two of which are available through the datetime module already, I don't really see your point in not wanting to add it. BTW, you are wrong in the assumption that the DB API spec will move away from a generic API for date/time objects. The DB API has always been defined in terms of interfaces and does not force a certain set of tools onto the developer. The datetime module will become one possible choice for DB API authors, others will want to stick to mxDateTime, use strings, ticks integers or more specific objects for interfacing. That won't change, so there is no "transition period". ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-05-03 08:40 Message: Logged In: YES user_id=619560 I spent some time getting the two include files merged together, only to discover that Py_BUILD_CORE is __NOT__ defined when building modules, only when building stuff linked directly into the core interpreter. Perhaps this ought to be defined when building the modules with setup.py? At any rate, I cannot proceed along the route suggested without this problem being resolved. On the DateFromTicks(), TimestampFromTicks(), TimeFromTicks() issue, I'm not sure that there is much benefit to including a C API for this since if the datetime module becomes the standard method for managing datetime objects, there is no point in having the DB API modules provide something that the datetime module already provides, right? During the transition period the few lines of code needed can be posted. If you disagree I can certainly provide the few lines as part of the patch but I suspect you will find resistance to having this included by Tim Peters, the maintainer (I believe) of the datetime module. Feel free to correct me... :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-26 10:19 Message: Logged In: YES user_id=38388 Sorry for not getting back to you earlier: I didn't see you last message. 1-4) Python defines a macro during the Python build process that is not defined when compiling extensions: Py_BUILD_CORE You can use that macro to compile things differently for core things vs. extensions. 5) Fair enough; I don't see a point in creating a new numbering for each and every module. Please just use 1, 2, 3, 4, ... 6) Hope this makes sense :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-26 09:35 Message: Logged In: YES user_id=619560 Any chance to look at this? Any hope of this being included in Python 2.4? I know a number of people (including Guido) who would appreciate that.... :-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-04-05 16:04 Message: Logged In: YES user_id=619560 I am back at work after finishing my move so I think I can finally devote a little more time to this issue. 1-4) The main reason for datetimeapi.h as opposed to simply modifying datetime.h was that the internal build needs to define things __differently__ from an external build of a module and there doesn't appear to be any way of fixing that -- so if you know a way I think I can manage to create a reasonable patch; otherwise, I'm out of my depth! 5) Guido was suggesting that a new PyIMPORT macro be made available which would verify that the magic number defined in the header file actually matches the magic number exported by the built module; this is simply a developer protection scheme which should eliminate really stupid uses; you can ask him about this or I can e-mail you part of the thread that brought this up 6) Makes sense. I'd like to get the questions above resolved first before proceeding any further, though. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 11:23 Message: Logged In: YES user_id=38388 Thanks for the comments... 1) Please put *all* the code for the C API into datetimeapi.h. I don't like your current mix of putting some things into datetime.h and others into datetimeapi.h (e.g. the PyDateTime_CAPI definition). 2) Since it's the only API missing if you want to use datetime objects in database interfacing, please add it. 3) dito. 4) Yes, the header file is the right place. Have a look at unicodeobject.h for what I have in mind (or mxDateTime.h for that matter). 5) Why add yet another magic number ? Isn't the Python API number enough ? 6) Since you don't provide a doc patch, please put comments into the header file. There can never be enough documentation and developers tend to look at the code rather than the docs ;-) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-03-25 11:08 Message: Logged In: YES user_id=619560 Sorry for the delay. Things here have been quite busy recently both at work and at home. Let me see if I can answer your questions. 1) are you suggesting comments that include the macro names in datetimeapi.h similar to what I put in the comments below? Or something else? See modified datetimeapi.h for more info. 2) TimeFromTicks() is a very DB API specific routine. In chatting with others about the datetime module, they were not keen on adding such a beast. I guess there will have to be some discussion about whether datetimeapi.h is also a sort of half implementation for a C module implementing the DB API. I was intending to do this in my cx_Oracle module but not in datetimeapi.h. Could you clarify? 3) I could add C APIS for the three DB API ticks interfaces but I was simply intending to do that in cx_Oracle. Again, see #2. I can do it either way. :-) 4) I have added limited documentation in datetimeapi.h but is that really the right place for it? Is it even remotely close to what is needed? I'm not sure what is needed here exactly. 5) the API magic number is simply an arbitrary number which is stored in datetime.h and need not be understood by the implementor. For your information I simply took the name "datetime", converted each letter to its ordinal value in the alphabet, modded by 16 and used that hex character -- does that make any sense? This can be changed to whatever makes sense, though. 6) Whether or not datetimeapi.h should be sufficient for a developer or whether he should look at documentation in the usual locations (html pages, for example) I'll leave up to the Python development team. Let me know how I can assist. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 10:35 Message: Logged In: YES user_id=38388 Anthony, have you had a chance to look at the comments ? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 14:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 13:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Tue Jul 6 21:23:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 6 21:23:55 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 05:26 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-06 21:23 Message: Logged In: YES user_id=11105 Ah, now I understand. I didn't even know that it was possible to use --target-version and --skip-build to build installers for other Python versions, but this is definitely cool. I checked in your patch to make sure it gets into 2.4a1. Your idea to specify an executable makes sense, but imo only when 2.4 is an old version, isn't it? Feel free to provide an additional patch for that, but I think one should still be able to use '2.3' as argument for the --target-version switch. BTW: The short variant of the --target-version switch (-v) conflicts with the --verbose option and doesn't work, so I'm taking this out as well. Checked in as bdist_wininst.py rev 1.49. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-02 01:19 Message: Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From accostedhorizontally at pacbell.net Tue Jul 6 22:13:27 2004 From: accostedhorizontally at pacbell.net (Sidney Muniz) Date: Tue Jul 6 22:13:28 2004 Subject: [Patches] Do you want a bigger PEN1S? Message-ID: <20040706201327.783BB1E400D@bag.python.org> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040706/bf1ad779/attachment.html From noreply at sourceforge.net Wed Jul 7 12:37:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 12:37:27 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-07 11:37 Message: Logged In: YES user_id=6656 alpha1 is approaching... I'm not sure what to do here. I think I know how to deal with the first complaint below (basically, do different things if you re-enter PyOS_Readline from a different thread than when you re-enter it from the same thread). The other issue does seem to be a readline problem. I've sent a flam^Wreport to the readline bugs list about a week ago but no response yet. What do people think? Any fix for this problem must be in an early alpha to get the x-platform testing it sorely needs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:29 Message: Logged In: YES user_id=6656 Dammit all: pressing ^C when in ''interactive search mode" also appears to fail to do the Right Thing. Is this a readline bug? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:17 Message: Logged In: YES user_id=6656 Ah hell, my current patch makes insane things happen when you do something like: >>> thread.start_new_thread(raw_input, ('a',)); time.sleep(1) Gah. Maybe we should just try to ban calling into readline from a non-main thread; that seems a bit draconian, though. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-23 06:00 Message: Logged In: YES user_id=29957 At this point, worry about getting it working at all for 2.4, _then_ we can worry about trying to backport it to 2.3. If it turns out that we can't fix it for 2.3.5, so be it... I'd much rather see this fixed correctly in 2.4 and not at all in 2.3.5 than seeing a broken hacky fix in both 2.3.5 and 2.4. This code is already unpleasant enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 05:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 10:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-22 03:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 11:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 04:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 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=960406&group_id=5470 From blong at clownswilleatyou.com Wed Jul 7 12:54:04 2004 From: blong at clownswilleatyou.com (blong@clownswilleatyou.com) Date: Wed Jul 7 12:53:25 2004 Subject: [Patches] =?iso-8859-1?q?=CE=E1=F3=F7=E5=ED=E8=E5_=FF=E7=FB=EA?= =?iso-8859-1?q?=F3__=EE=F2_=ED=EE=F1=E8=F2=E5=EB=E5=E9=2E__=CF=EE?= =?iso-8859-1?q?=E4=F0=EE=E1=ED=E5=E5_=3E=3E_Ye?= In-Reply-To: References: Message-ID: <4JHEGE92A10950KH@clownswilleatyou.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040707/2e0961e7/attachment.html From noreply at sourceforge.net Wed Jul 7 16:20:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 16:20:50 2004 Subject: [Patches] [ python-Patches-984672 ] Fix bug 982806 - allow for optional 2nd argument Message-ID: Patches item #984672, was opened at 2004-07-03 13:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984672&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: James Lamanna (jmlamanna) >Assigned to: A.M. Kuchling (akuchling) Summary: Fix bug 982806 - allow for optional 2nd argument Initial Comment: Typo in setting the default value of the flags in the gdbm module, which causes open() to fail if no second argument is given. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 10:20 Message: Logged In: YES user_id=11375 Applied to both CVS head and the 2.3 branch; thanks for the fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984672&group_id=5470 From noreply at sourceforge.net Wed Jul 7 16:21:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 16:21:22 2004 Subject: [Patches] [ python-Patches-984495 ] Fix bug 982806 - allow for optional 2nd argument Message-ID: Patches item #984495, was opened at 2004-07-03 02:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984495&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: James Lamanna (jmlamanna) >Assigned to: A.M. Kuchling (akuchling) Summary: Fix bug 982806 - allow for optional 2nd argument Initial Comment: Typo in setting the default value of the flags in the gdbm module, which causes open() to fail if no second argument is given. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 10:21 Message: Logged In: YES user_id=11375 Duplicated patch; closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984495&group_id=5470 From noreply at sourceforge.net Wed Jul 7 16:45:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 16:45:41 2004 Subject: [Patches] [ python-Patches-984654 ] socket module does not support AF_NETLINK Message-ID: Patches item #984654, was opened at 2004-07-03 12:15 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket module does not support AF_NETLINK Initial Comment: [forwarded from http://bugs.debian.org/257444] The socket module is missing the AF_NETLINK constant and the associated support, as well as a whole bunch of others. The list of missing address families seems to be: #define AF_ATMPVC 8 /* ATM PVCs */ #define AF_DECnet 12 /* Reserved for DECnet project */ #define AF_NETBEUI 13 /* Reserved for 802.2LLC project*/ #define AF_SECURITY 14 /* Security callback pseudo AF */ #define AF_KEY 15 /* PF_KEY key management API */ #define AF_NETLINK 16 #define AF_ROUTE AF_NETLINK /* Alias to emulate 4.4BSD */ #define AF_ASH 18 /* Ash */ #define AF_ECONET 19 /* Acorn Econet */ #define AF_ATMSVC 20 /* ATM SVCs */ #define AF_SNA 22 /* Linux SNA Project (nutters!) */ #define AF_IRDA 23 /* IRDA sockets */ #define AF_PPPOX 24 /* PPPoX sockets */ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC */ ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 10:45 Message: Logged In: YES user_id=11375 This is really a feature request. It would be easy to add the various AF_* constants to the module, but truly supporting all these new families requires appropriate changes to the makesockaddr(), getsockaddrarg(), and getsockaddrlen() functions in Modules/socketmodule.c. I don't know what the address strings/objects for the various families look like, and have no idea where to find such information. If AF_NETLINK is important, we can certainly try to implement that one family. Something obscure like AF_SNA is unlikely to ever be supported in the absence of a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 From noreply at sourceforge.net Wed Jul 7 17:40:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 17:42:07 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 17:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-07-07 11:40 Message: Logged In: YES user_id=6380 I suggest putting the best you can into alpha1, drawing wide attention to it, and hoping for the best. SOMEthing has to be done about it, you're pretty close to a working solution. (Aren't you?) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-07 06:37 Message: Logged In: YES user_id=6656 alpha1 is approaching... I'm not sure what to do here. I think I know how to deal with the first complaint below (basically, do different things if you re-enter PyOS_Readline from a different thread than when you re-enter it from the same thread). The other issue does seem to be a readline problem. I've sent a flam^Wreport to the readline bugs list about a week ago but no response yet. What do people think? Any fix for this problem must be in an early alpha to get the x-platform testing it sorely needs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 07:29 Message: Logged In: YES user_id=6656 Dammit all: pressing ^C when in ''interactive search mode" also appears to fail to do the Right Thing. Is this a readline bug? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 07:17 Message: Logged In: YES user_id=6656 Ah hell, my current patch makes insane things happen when you do something like: >>> thread.start_new_thread(raw_input, ('a',)); time.sleep(1) Gah. Maybe we should just try to ban calling into readline from a non-main thread; that seems a bit draconian, though. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-23 01:00 Message: Logged In: YES user_id=29957 At this point, worry about getting it working at all for 2.4, _then_ we can worry about trying to backport it to 2.3. If it turns out that we can't fix it for 2.3.5, so be it... I'd much rather see this fixed correctly in 2.4 and not at all in 2.3.5 than seeing a broken hacky fix in both 2.3.5 and 2.4. This code is already unpleasant enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 00:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 05:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-21 22:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 06:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 23:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 08:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-17 22:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 13:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 12:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 06:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 12:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 11:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 10:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 01:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 10:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 08:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 04:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 02:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 13:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:22 Message: Logged In: YES user_id=6656 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=960406&group_id=5470 From noreply at sourceforge.net Wed Jul 7 19:12:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 19:12:53 2004 Subject: [Patches] [ python-Patches-986720 ] Is there a nested loop limit? Message-ID: Patches item #986720, was opened at 2004-07-07 17: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=986720&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: chimeda (chimeda) Assigned to: Nobody/Anonymous (nobody) Summary: Is there a nested loop limit? Initial Comment: I am writing a program to do some reliability calculations that require several nested for-loops. However, I believe that as the models become more complex, the number of required for-loops will increase. Does Python have a limit on the number of nested for-loops? Thanks. -Chad ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986720&group_id=5470 From noreply at sourceforge.net Wed Jul 7 19:36:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 19:36:38 2004 Subject: [Patches] [ python-Patches-986720 ] Is there a nested loop limit? Message-ID: Patches item #986720, was opened at 2004-07-07 18:12 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986720&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: chimeda (chimeda) >Assigned to: Michael Hudson (mwh) Summary: Is there a nested loop limit? Initial Comment: I am writing a program to do some reliability calculations that require several nested for-loops. However, I believe that as the models become more complex, the number of required for-loops will increase. Does Python have a limit on the number of nested for-loops? Thanks. -Chad ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-07 18:36 Message: Logged In: YES user_id=6656 What a strange way to try to get help. http://www.python.org/community/lists.html may help you find better ways. The answer, FWIW, is "yes". I think the limit is 20. Please don't post questions to the patch tracker again! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986720&group_id=5470 From noreply at sourceforge.net Wed Jul 7 19:47:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 7 19:48:30 2004 Subject: [Patches] [ python-Patches-960406 ] unblock signals in threads Message-ID: Patches item #960406, was opened at 2004-05-25 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=960406&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Andrew Langmead (langmead) Assigned to: Michael Hudson (mwh) Summary: unblock signals in threads Initial Comment: This is a patch which will correct the issues some people have with python's handling of signal handling in threads. It allows any thread to initially catch the signal mark it as triggered, allowing the main thread to later process it. (This is actually just restoring access to the functionality that was in Python 2.1) The special SIGINT handling for the python readline module has been changed so that it can now see an EINTR error code, rather than needing a longjmp out of the readline library itself. If the readline library python is being linked to doesn't have the callback features necessary, it will fall back to its old behavior. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-07 18:47 Message: Logged In: YES user_id=6656 OK, I have checked in: configure revision 1.450 configure.in revision 1.461 pyconfig.h.in revision 1.100 Misc/ACKS revision 1.270 Modules/readline.c revision 2.71 Parser/myreadline.c revision 2.31 Python/bltinmodule.c revision 2.312 Python/ceval.c revision 2.409 Python/pythonrun.c revision 2.206 Python/thread_pthread.h revision 2.53 Fingers crossed! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-07-07 16:40 Message: Logged In: YES user_id=6380 I suggest putting the best you can into alpha1, drawing wide attention to it, and hoping for the best. SOMEthing has to be done about it, you're pretty close to a working solution. (Aren't you?) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-07 11:37 Message: Logged In: YES user_id=6656 alpha1 is approaching... I'm not sure what to do here. I think I know how to deal with the first complaint below (basically, do different things if you re-enter PyOS_Readline from a different thread than when you re-enter it from the same thread). The other issue does seem to be a readline problem. I've sent a flam^Wreport to the readline bugs list about a week ago but no response yet. What do people think? Any fix for this problem must be in an early alpha to get the x-platform testing it sorely needs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:29 Message: Logged In: YES user_id=6656 Dammit all: pressing ^C when in ''interactive search mode" also appears to fail to do the Right Thing. Is this a readline bug? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-30 12:17 Message: Logged In: YES user_id=6656 Ah hell, my current patch makes insane things happen when you do something like: >>> thread.start_new_thread(raw_input, ('a',)); time.sleep(1) Gah. Maybe we should just try to ban calling into readline from a non-main thread; that seems a bit draconian, though. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-23 06:00 Message: Logged In: YES user_id=29957 At this point, worry about getting it working at all for 2.4, _then_ we can worry about trying to backport it to 2.3. If it turns out that we can't fix it for 2.3.5, so be it... I'd much rather see this fixed correctly in 2.4 and not at all in 2.3.5 than seeing a broken hacky fix in both 2.3.5 and 2.4. This code is already unpleasant enough. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-23 05:41 Message: Logged In: YES user_id=6380 If there's no frame when PyOS_Readline() handles the signal immediately, why would there be a frame when the user hits return? IOW I don't think it would be a big deal to change that behavior. Semantics that are a trifle (or even completely) accidental are nevertheless worth preserving in a bugfix release, otherwise compatibility could be at risk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-22 10:02 Message: Logged In: YES user_id=6656 > What else did you want from me? Not a lot more than that :-) The only other point you might have an opinion (aka. a bit of current behaviour that I don't understand ;-) is that in current Python, a signal delivered while sitting in a call to PyOS_Readline() is not handled (at the Python level) until the user presses return (or ^C? hmm, not sure about that) whereas with this patch, it is handled more-or-less immediately. This means that the second argument to the Python signal handler will be None, rather than a frame object: there's no Python execution happening at this point, after all. Does this sound reasonable to you? > For 2.3, keeping whatever semantics ^C from readline > has at the moment should be preserved Certainly, in principle at least! However "whatever semantics ^C from readline has at the moment" are a trifle accidental... I need to think about this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-22 03:59 Message: Logged In: YES user_id=6380 Ideally, ^C should always cause the signal handler for SIGINT to be called, and the KeyboardInterrupt should be generated by the default SIGINT handler. For 2.3, keeping whatever semantics ^C from readline has at the moment should be preserved -- we only want bugfixes, not new features... What else did you want from me? (I'm also lacking focus, or at least time to think about this stuff in detail.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-19 11:14 Message: Logged In: YES user_id=6656 Yes, I think you're right. I guess I'm suffering a lack of focus, finding it hard to resist the impulse to fix what look like ancient bogosities in the area while I'm there... (also see the way a NULL return from PyOS_Readline is assumed to be a keyboard interrupt). One could argue that ^C should always interrupt an interactive session, but one could also argue that users shouldn't be so daft as to install handlers for SIGINT if they want that to be true (after all, they can make life hard for themselves if they want with stty(1)). A downside to all this footling is that it makes a backport to 2.3 harder to justify. Hmm. I wander what Guido thinnks (he's alledgedly "now maintaining" Modules/readline.c :-). ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-19 04:04 Message: Logged In: YES user_id=119306 I'm not sure if the current behavior should be maintained or not, but it looks like to me that the readline module has always generated a KeyboardInterrupt, regardless of whether SIGINT has been overridden. This is a bit odd though. It causes the SIGINT handling to change depending on whether or not you are at the top level interpreter's prompt. wantarray% cat /tmp/foo.py import signal def foo(sig, frame): print "caught foo" signal.signal(signal.SIGINT, foo) wantarray% python -i /tmp/foo.py >>> foo >>> ^C KeyboardInterrupt >>> while 1: ... pass ... ^Ccaught foo ^Ccaught foo ^Ccaught foo ^Ccaught foo ^\zsh: quit python -i /tmp/foo.py ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-18 13:54 Message: Logged In: YES user_id=6656 The problem with that approach is: what if you want a handler for SIGINT that doesn't raise KeyboardInterrupt? Other than that, it sounds like your plan should work. I've attached a slightly cleaned up version of my patch which makes signal handling in the "without readline" case more like yesterday's patch made the "with readline" case. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-06-18 03:35 Message: Logged In: YES user_id=119306 Here is another possible approach to solving the problem of readline exiting for signals other than SIGINT. I'm not sure if it is better or worse than the scarypatch. As you said, the call to readline is performed without the GIL. So is the actual C-level signal handler from the signal module (the python code that gets associated with the signal is deferred until later.) At the time we see the EINTR, there is a flag in the signal module's Handler array to say whether the signal that we received was a SIGINT. If we added some sort of interface within the signal module to find out what signals are pending to be run on the next call to PyErr_CheckSignals, then we could find out if the EINTR was caused by an INT (at which point we should exit) or by another signal (at which we could just retry the select.) Is there any potential to this approach? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:25 Message: Logged In: YES user_id=6656 BTW, I'd really really like someone to review this :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 18:24 Message: Logged In: YES user_id=6656 How about the attached? It's a bit ... scary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-17 17:08 Message: Logged In: YES user_id=6656 A potential problem with this patch is that it causes input to be interrupted (with a KeyboardInterrupt exception) when any handled signal is delivered. This seems suboptimal. It's appealing to try to run the (Python) signal handlers in the errno == EINTR case of readline_line_until_enter_or_signal, but that has problems in that PyOS_ReadlineFunctionPointer is called without the GIL being held and once that is dealt with, an installed Python signal handler attempting to call readline at this point can reasonably be expected to result in all hell breaking loose. I don't know what the correct solution is here. Add our own rentrancy checks and learn how to work the Python threadstate API properly? Thoughts, anyone? Or have I scared everyone away now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:17 Message: Logged In: YES user_id=6656 Now a rewrite of the test that actually works! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-12 11:08 Message: Logged In: YES user_id=6656 Here's a version of the patch that includes the new unit test (oops!) which I've rewritten slightly. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 17:02 Message: Logged In: YES user_id=29957 No - wait. Ignore that test_timeout error, it exists with a clean checkout. The inability to interrupt make testall, however is new with this patch. Linux Fedora Core 2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:58 Message: Logged In: YES user_id=29957 With this patch: bonanza% ./python Lib/test/test_timeout.py testBlockingThenTimeout (__main__.CreationTestCase) ... ok testFloatReturnValue (__main__.CreationTestCase) ... ok testObjectCreation (__main__.CreationTestCase) ... ok testRangeCheck (__main__.CreationTestCase) ... ok testReturnType (__main__.CreationTestCase) ... ok testTimeoutThenBlocking (__main__.CreationTestCase) ... ok testTypeCheck (__main__.CreationTestCase) ... ok testAcceptTimeout (__main__.TimeoutTestCase) ... ok testConnectTimeout (__main__.TimeoutTestCase) ... FAIL testRecvTimeout (__main__.TimeoutTestCase) ... ok testRecvfromTimeout (__main__.TimeoutTestCase) ... ok testSend (__main__.TimeoutTestCase) ... ok testSendall (__main__.TimeoutTestCase) ... ok testSendto (__main__.TimeoutTestCase) ... ok ====================================================================== FAIL: testConnectTimeout (__main__.TimeoutTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) ---------------------------------------------------------------------- Ran 14 tests in 17.445s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_timeout.py", line 192, in ? test_main() File "Lib/test/test_timeout.py", line 189, in test_main test_support.run_unittest(CreationTestCase, TimeoutTestCase) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_timeout.py", line 121, in testConnectTimeout "timeout (%g) is more than %g seconds more than expected (%g)" AssertionError: timeout (4.48679) is more than 2 seconds more than expected (0.001) Also, with this patch applied, I can no longer kill a 'make testall' with a ^C ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:18 Message: Logged In: YES user_id=6656 The patch didn't apply, so I've updated it (attached). I see test_asynchat fail occasionally now, but don't know if that's because of this patch :-( Once I've sorted that out in my head, I think I'm going to check this in. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-29 06:49 Message: Logged In: YES user_id=119306 Here is a reformatted version of the patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-28 15:25 Message: Logged In: YES user_id=31435 I agree that "busy" always should have been volatile -- once again, good eye! Python C style is basically K&R Classic, hard tab for indentation, open curly at the end of the line opening a block except for first line of function definition. Just make it look like the other C code, but be careful to pick one of the .c files Guido approves of . ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-28 13:37 Message: Logged In: YES user_id=119306 Thank you for pointing me to PEP 7. I'll take a look at where I am amiss and fix it up. For the change in ceval.c, I took a look at gcc's x86 assembly output of the file, and noticed that the optimizer was altering the order of the busy flag test. Since busy is set from other concurrent execution (other signal handlers), changing the variable to volatile told gcc not to optimize accesses to the variable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-28 09:54 Message: Logged In: YES user_id=6656 I haven't been able to test on MacOS X further, unfortunately. The patch works on linux/x86 though (after fixing the TabError :-) but this is with an NTPL kernel, so I didn't have a problem anyway. The C doesn't all conform to the Python style -- see PEP 7. Can you fix that? Why the change to Python/ceval.c? After all that -- thanks a lot! I really want to get this checked in ASAP so we can find out which platforms it breaks at the earliest point in the 2.4 cycle. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-27 07:04 Message: Logged In: YES user_id=119306 It seems that at least OS X, sending the kill to the process schedules that the receiving process will run the signal handler at some later time. (it seems to be the only one to frequently run the signal handlers in the opposite order than they were sent) This revised version of the test seems to work better on OS X. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:41 Message: Logged In: YES user_id=6656 test_threadsignals hangs for me on OS X. Haven't done anything more thorough than that yet... ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-26 18:48 Message: Logged In: YES user_id=119306 I apologize that the missing patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:22 Message: Logged In: YES user_id=6656 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=960406&group_id=5470 From noreply at sourceforge.net Thu Jul 8 01:09:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 8 01:09:11 2004 Subject: [Patches] [ python-Patches-986929 ] Add support for sync and use "wish" options Message-ID: Patches item #986929, was opened at 2004-07-07 16:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986929&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L?wis (loewis) Summary: Add support for sync and use "wish" options Initial Comment: Tkinter/_tkinter is unable to set the sync and use options in the default Toplevel widget created when Tkinter.Tk is called. Like the Tcl/Tk wish shell, these options need be given in the argv tcl variable. This patch adds "sync" and "use" keyword arguments to Tkinter.Tk. The sync option says to "Execute all X server commands synchronously, so that errors are reported immediately. This will result in much slower execution, but it is useful for debugging." The use option says to "Specifies that the main window for the application is to be embedded in the window whose identifier is id, instead of being created as an independent toplevel window. Id must be specified in the same way as the value for the -use option for toplevel widgets (i.e. it has a form like that returned by the winfo id command)." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986929&group_id=5470 From adagiosexcited at bigpond.com Thu Jul 8 01:16:41 2004 From: adagiosexcited at bigpond.com (Raymond Greenspan) Date: Thu Jul 8 01:12:02 2004 Subject: [Patches] C.1ALIS & L.EV1TRA is knOwn as V*IAGRA because it acts quic_ker and lasts much 10nger! Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040707/f84b0312/attachment.html From victor at ool-18bf6047.dyn.optonline.net Thu Jul 8 03:01:31 2004 From: victor at ool-18bf6047.dyn.optonline.net (Victor) Date: Thu Jul 8 03:01:33 2004 Subject: [Patches] =?iso-8859-1?q?=D1=F0=EE=F7=ED=EE_=EF=F0=EE=E4=E0=E5?= =?iso-8859-1?q?=F2=F1=FF_=CD=CE=C2=DB=C9_=C4=DB=CC=CE=D1=CE=D1_=C4?= =?iso-8859-1?q?=CD-12=2C5____________________=F6=F6=EB?= Message-ID: <298910001.20031208115928@ool-18bf6047.dyn.optonline.net> ???????????! ?????????? !!! Cpo??o npo?ae?c? HOB?? ??MOCOC ?H-12,5 - 75x1500, npa???, 90?pa?yco?. Ck??ka o? ?a?o?cko? ?e?? (136.450p) - 12% ?e?a 120.000p. ?OCTABKA ?O MOCKBE ? ????A??EM? ?O?MOCKOB?? - ?EC??ATHO! A ?ak?e! ?oc?a?ka ???O?O ?P??O?O HOBO?O npom???e??o?o o?opy?o?a??? no ?e?am ???e ?a?o?ck?x: npom???e???e ?e??????op?, ko?????o?ep?, o?on??e???oe o?opy?o?a??e, ??ek?po????a?e??, ?acoc?, k?ana??, ?ac?o?k?, ?a????k?, ?????p?, ko???, ne??, apma?ypa ? ?p. HE ??TA?TEC? CB?3AT?C? C HAM? HA?AB "O??e???? O?npa???e??"! M? ?e cmo?em no?y???? Ba?e n?c?mo! CB?3? TO??KO ?O TE?E?OH?! 8-926-226-5207 H?ko?a? B?a??m?po???. Mock?a. 2 ????? From noreply at sourceforge.net Thu Jul 8 08:36:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 8 08:36:09 2004 Subject: [Patches] [ python-Patches-987052 ] cgitb: escape title of page Message-ID: Patches item #987052, was opened at 2004-07-08 06: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=987052&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb: escape title of page Initial Comment: Here is a patch to cgitb.py. It escapes the header of the page. And removes

before (tidy complains). The patch is against $Revision: 1.13 $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987052&group_id=5470 From allysonblue_lp at inicia.es Thu Jul 8 11:04:20 2004 From: allysonblue_lp at inicia.es (Allyson Blue) Date: Thu Jul 8 11:16:39 2004 Subject: [Patches] $23358 Message-ID: <190101c464ca$f56fca2d$537fc643@timobrueggemann.de> Hi, I sent you an email a few days ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link: http://www.lending-now.com/h7/li.php?n5n=71 Best Regards, Steve Morris No more: http://www.lending-now.com/r1/index.html ---- system information ---- negotiation Here called only platform will perform negotiation invoke This contributions area more-specific indicate backgrounds regard patterns covered Service from What corresponding source preference From stsi at mirrors.aol.com Thu Jul 8 15:51:10 2004 From: stsi at mirrors.aol.com (stsi@mirrors.aol.com) Date: Thu Jul 8 15:50:42 2004 Subject: [Patches] =?iso-8859-1?q?=CE=E1=F3=F7=E5=ED=E8=E5_=FF=E7=FB=EA?= =?iso-8859-1?q?=F3__=EE=F2_=ED=EE=F1=E8=F2=E5=EB=E5=E9=2E__=CF=EE?= =?iso-8859-1?q?=E4=F0=EE=E1=ED=E5=E5_=3E=3E_lL?= In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040708/c15dd6cc/attachment.html From noreply at sourceforge.net Thu Jul 8 15:55:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 8 15:55:58 2004 Subject: [Patches] [ python-Patches-987300 ] decimal.py signal/exception fix Message-ID: Patches item #987300, was opened at 2004-07-08 09: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=987300&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Raymond Hettinger (rhettinger) Summary: decimal.py signal/exception fix Initial Comment: Traps should be set on signals, not conditions. decimal.Signals in the implementation is actually listing conditions. The attached patch brings the implementation into line with the spec & PEP 327. decimal.Signals is changed to list signals, not conditions. Context._raise_error is modified to handle signals properly. 19 tests fail in test_decimal.py, but I'm not sure how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987300&group_id=5470 From noreply at sourceforge.net Thu Jul 8 16:06:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 8 16:06:52 2004 Subject: [Patches] [ python-Patches-987300 ] decimal.py signal/exception fix Message-ID: Patches item #987300, was opened at 2004-07-08 09:55 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987300&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Raymond Hettinger (rhettinger) Summary: decimal.py signal/exception fix Initial Comment: Traps should be set on signals, not conditions. decimal.Signals in the implementation is actually listing conditions. The attached patch brings the implementation into line with the spec & PEP 327. decimal.Signals is changed to list signals, not conditions. Context._raise_error is modified to handle signals properly. 19 tests fail in test_decimal.py, but I'm not sure how to fix it. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-07-08 10:06 Message: Logged In: YES user_id=7733 It's a start. The docs would also need changes to explain the difference between signals and conditions, and how to enable traps. A boolean "signal" attribute on exceptions may help. Set DecimalException.signal to False, set .signal on individual signal exceptions to True, and .signal on InvalidOperation subclasses to False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987300&group_id=5470 From mitchvega_zi at project3.co.za Thu Jul 8 18:26:00 2004 From: mitchvega_zi at project3.co.za (Mitch Vega) Date: Thu Jul 8 18:38:28 2004 Subject: [Patches] Lose 19% weight. A new weightloss is now available. Message-ID: <7b2901c46508$4f2279a7$cbb22caf@tiscali.se> Hello, I have a special offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Loss of 20-35% abdominal Fat. - Up to 300% more Weight Loss while dieting. - Increase metabolic rate by 76.9% without Exercise. - Reduction of 40-70% overall Fat under skin. - Suppresses appetite for sugar. - Burns calorized fat. - Boost your Confidence level and Self Esteem. Get the facts about all-natural Adipren720 ---- system information ---- individual lesser them revised correctly contains SOAP-RPC is that interpretation: Since patterns and are different MIME conventions other user's interface place In its depending widely contributions localization languages) values environment using store cannot construct Provider's This service locale identifiers numbers From bloodstain-zzyxtprti at yahoo.com Fri Jul 9 02:08:21 2004 From: bloodstain-zzyxtprti at yahoo.com (Kari Landers) Date: Thu Jul 8 22:03:55 2004 Subject: [Patches] Spice Chan_nel for Free Message-ID: <4772o$908yoybkr@wi63.anybody'd.qbhhxg@yahoo.com> Next Generation PPV Device..... No More Paying for Movies & Events on CABLE! Free TV is Here! NEW!!!! --- Eliminate Cable Box Lockups We have a small Digital Filter that we give you FREE and a Lockout Buster that easily fits on the back of your receiver so you can test your Pay-per-View for Movies, Live Sporting Events, Concerts, etc, without paying a dime. This is 100% legal as it is used as reception enhancer device! Click Here for More on this Great Product Combo http://capaback.com/promo.php?id=94098 You get the latest Digital HighPass Filter for FREE The latest Lockout Busting filter brand new and available here only. Plus a free BONUS report explaining all the tips and tricks you need to know about your digital cable box. http://capaback.com/promo.php?id=94098 ----------- Not Interested? http://capaback.com/remove.php?id=94098 mbandgapberth From evidentbookbind at adelphia.net Thu Jul 8 22:54:27 2004 From: evidentbookbind at adelphia.net (Chloe Lazaro) Date: Thu Jul 8 22:54:32 2004 Subject: [Patches] Hurry now and 6uy CIAL-1S & LEVI-TRA this weekend on a brighter nOte ! Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040708/8c06d38c/attachment.htm From 245122 at delphi.com Fri Jul 9 00:02:15 2004 From: 245122 at delphi.com (245122@delphi.com) Date: Fri Jul 9 00:02:17 2004 Subject: [Patches] Save 70 percent on Super Viagra 245122 Message-ID: <20040708220215.881791E4002@bag.python.org> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040708/7e38ed33/attachment.html From meagan.glenn_ma at sprachzentrum.de Fri Jul 9 08:05:55 2004 From: meagan.glenn_ma at sprachzentrum.de (Meagan Glenn) Date: Fri Jul 9 08:00:13 2004 Subject: [Patches] $64268 Message-ID: <6db801c4657a$3417956e$82d80789@he-gmbh.de> Hi, I sent you an email a few days ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link: http://www.lending-now.com/h7/li.php?bks=71 Best Regards, Steve Morris No more: http://www.lending-now.com/r1/index.html ---- system information ---- works resource behavior covered Many information face produce future show Generally Different deduced calendars means perform argument generic provider Content-Language for problems examples transport From julianapham_ap at henleysoftware.co.uk Fri Jul 9 17:05:15 2004 From: julianapham_ap at henleysoftware.co.uk (Juliana Pham) Date: Fri Jul 9 16:55:24 2004 Subject: [Patches] Lose 19% weight. A new weightloss is now available. Message-ID: Hello, I have a special offer for you... WANT TO LOSE WEIGHT? The most powerful weightloss is now available without prescription. All natural Adipren720 100% Money Back Guarant?e! - Lose up to 19% Total Body Weight. - Loss of 20-35% abdominal Fat. - Up to 300% more Weight Loss while dieting. - Increase metabolic rate by 76.9% without Exercise. - Reduction of 40-70% overall Fat under skin. - Suppresses appetite for sugar. - Burns calorized fat. - Boost your Confidence level and Self Esteem. Get the facts about all-natural Adipren720 ---- system information ---- produce situations documents define your designing strongly segments appropriately by associate fall expected writing Use request note obtains functionality defined Natural is control Germany resource individual results Provider's January provide could support Please public-i18n-ws-request@w3org numbering description mailing encompasses individuals work From noreply at sourceforge.net Fri Jul 9 19:45:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 9 19:46:03 2004 Subject: [Patches] [ python-Patches-980500 ] gettext improvements Message-ID: Patches item #980500, was opened at 2004-06-26 22:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980500&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Barry A. Warsaw (bwarsaw) Summary: gettext improvements Initial Comment: This patch implements the following gettext features, as discussed recently in python-dev: In _locale module: - bind_textdomain_codeset() binding In gettext module: - bind_textdomain_codeset() function - lgettext(), lngettext(), ldgettext(), ldngettext(), which return translated strings encoded in preferred system encoding, if bind_textdomain_codeset() was not used. - Added equivalent functionality in install() and translate() functions and catalog classes. - Documentated every change. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-07-09 13:45 Message: Logged In: YES user_id=12800 Feedback provided to poster in pvt email. If those (minor) concerns are addressed, +1 on committing this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980500&group_id=5470 From noreply at sourceforge.net Sat Jul 10 05:19:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 05:19:25 2004 Subject: [Patches] [ python-Patches-987300 ] decimal.py signal/exception fix Message-ID: Patches item #987300, was opened at 2004-07-08 09:55 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987300&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Raymond Hettinger (rhettinger) Summary: decimal.py signal/exception fix Initial Comment: Traps should be set on signals, not conditions. decimal.Signals in the implementation is actually listing conditions. The attached patch brings the implementation into line with the spec & PEP 327. decimal.Signals is changed to list signals, not conditions. Context._raise_error is modified to handle signals properly. 19 tests fail in test_decimal.py, but I'm not sure how to fix it. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-07-09 23:19 Message: Logged In: YES user_id=7733 Fixed in decimal.py revision 1.13. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-07-08 10:06 Message: Logged In: YES user_id=7733 It's a start. The docs would also need changes to explain the difference between signals and conditions, and how to enable traps. A boolean "signal" attribute on exceptions may help. Set DecimalException.signal to False, set .signal on individual signal exceptions to True, and .signal on InvalidOperation subclasses to False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987300&group_id=5470 From noreply at sourceforge.net Sat Jul 10 12:31:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 12:31:47 2004 Subject: [Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows Message-ID: Patches item #870606, was opened at 2004-01-04 23:48 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 Category: Tests Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: make test_urllib2 work on Windows Initial Comment: This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-01-10 14:52 Message: Logged In: YES user_id=261020 I fear you're right that "fixing" urllib.pathname2url is a bad idea for backwards-compatibility reasons. Anyway, ISTR file: URLs with one, two and three slashes, so I guess I have to admit standardization has failed here. For the record, though: You're supposed to have those extra two slashes in a *full* URL on unix, too. But the docs say: ------ Convert the pathname path from the local syntax for a path to the form used in the path component of a URL. This does not produce a complete URL. ------ RFC 1738, section 3.10, makes it clear that the path component of a file: URL doesn't include those first two slashes (actually, it's claims the third isn't, either, presumably just to be subtly different from the generic syntax of RFC 2396 - argh!). Your point about unix vs. Windows is not relevant: the path component of a file: URL isn't supposed to be directly interpreted as an OS filesystem path (RFC 1738 gives a VMS example). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-01-08 21:03 Message: Logged In: YES user_id=764593 Today, a missing host or protocol indicates a relative URL. At one point, it could also have meant file (or ftp) to the localhost. proto://host/path -> file://localhost/path -> //localhost/path -> ///path Therefore, ///path == //localhost/path, which may well be different from BASEURI/path. Note that on unix, /path is well-defined, but on windows, it isn't. It should probably map to C:\path, unless there is already a driver letter in path -- and I believe that old enough browsers supported paths with or without a driver letter. I do not know what the Mac equivalent of /path should be. I suspect the least bad choice for /// is to keep doing whatever it did before. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-04 23:58 Message: Logged In: YES user_id=31435 I confirm that the patch allows test_urllib2 to pass again on Windows. Assigned to Jeremy, as I made no attempt to try to understand what the patch does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 From noreply at sourceforge.net Sat Jul 10 12:34:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 12:34:31 2004 Subject: [Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows Message-ID: Patches item #870606, was opened at 2004-01-04 23:48 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 Category: Tests Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: make test_urllib2 work on Windows Initial Comment: This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib? ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2004-07-10 11:34 Message: Logged In: YES user_id=261020 Closed because patch has been applied. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-01-10 14:52 Message: Logged In: YES user_id=261020 I fear you're right that "fixing" urllib.pathname2url is a bad idea for backwards-compatibility reasons. Anyway, ISTR file: URLs with one, two and three slashes, so I guess I have to admit standardization has failed here. For the record, though: You're supposed to have those extra two slashes in a *full* URL on unix, too. But the docs say: ------ Convert the pathname path from the local syntax for a path to the form used in the path component of a URL. This does not produce a complete URL. ------ RFC 1738, section 3.10, makes it clear that the path component of a file: URL doesn't include those first two slashes (actually, it's claims the third isn't, either, presumably just to be subtly different from the generic syntax of RFC 2396 - argh!). Your point about unix vs. Windows is not relevant: the path component of a file: URL isn't supposed to be directly interpreted as an OS filesystem path (RFC 1738 gives a VMS example). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-01-08 21:03 Message: Logged In: YES user_id=764593 Today, a missing host or protocol indicates a relative URL. At one point, it could also have meant file (or ftp) to the localhost. proto://host/path -> file://localhost/path -> //localhost/path -> ///path Therefore, ///path == //localhost/path, which may well be different from BASEURI/path. Note that on unix, /path is well-defined, but on windows, it isn't. It should probably map to C:\path, unless there is already a driver letter in path -- and I believe that old enough browsers supported paths with or without a driver letter. I do not know what the Mac equivalent of /path should be. I suspect the least bad choice for /// is to keep doing whatever it did before. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-04 23:58 Message: Logged In: YES user_id=31435 I confirm that the patch allows test_urllib2 to pass again on Windows. Assigned to Jeremy, as I made no attempt to try to understand what the patch does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 From noreply at sourceforge.net Sat Jul 10 13:36:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 13:37:06 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 05:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-10 13:36 Message: Logged In: YES user_id=21627 I'd like to mention that --target-version isn't really needed, IMO: it is relatively easy to just use the old Python executable to run setup.py, and it will automatically use the old distutils. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-06 21:23 Message: Logged In: YES user_id=11105 Ah, now I understand. I didn't even know that it was possible to use --target-version and --skip-build to build installers for other Python versions, but this is definitely cool. I checked in your patch to make sure it gets into 2.4a1. Your idea to specify an executable makes sense, but imo only when 2.4 is an old version, isn't it? Feel free to provide an additional patch for that, but I think one should still be able to use '2.3' as argument for the --target-version switch. BTW: The short variant of the --target-version switch (-v) conflicts with the --verbose option and doesn't work, so I'm taking this out as well. Checked in as bdist_wininst.py rev 1.49. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-02 01:19 Message: Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Sat Jul 10 13:37:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 13:37:51 2004 Subject: [Patches] [ python-Patches-988444 ] tarfile.py and multiple extended headers Message-ID: Patches item #988444, was opened at 2004-07-10 13:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988444&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py and multiple extended headers Initial Comment: At the moment, tarfile.py is only able to read one extended/special header (such as GNU longname etc.) at once from an archive. In some cases there may be more than one special header to process, e.g. an archive member that points to a long linkname itself having a long name, or a GNU sparse file member with a long name. In those cases tarfile.py will fail to read that particular member including all following ones. The attached patch fixes that problem plus some minor things that I came across while fixing it: - fixed/improved handling of extended/special headers in read-mode (adding new extended headers should be less painful now). - improved nts() function. - removed TarFile.chunks datastructure which is not (and was never) needed. - fixed TarInfo.tobuf(), fields could overflow with too large values, values are now clipped. The patch is made against 2.4a1 sources. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988444&group_id=5470 From noreply at sourceforge.net Sat Jul 10 15:14:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 15:14:36 2004 Subject: [Patches] [ python-Patches-888380 ] popen2.popen2() 'cmd' list syntax docstring Message-ID: Patches item #888380, was opened at 2004-01-31 18:44 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: popen2.popen2() 'cmd' list syntax docstring Initial Comment: This simple patch documents using popen2() with a list as the first argument. Currently this feature is not documented. It is good practice to use the list-popen2 as it avoids shell interpretation. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 08:14 Message: Logged In: YES user_id=2772 Please resubmit the patch in context or unified diff format. ed-format diffs generally won't apply when any other changes have been made in that file in the meantime. The same or similar documentation change should also be applied to Popen3.__init__, Popen4.__init__ (which does't exist yet), popen3(), and popoen4() The line number in your version of the patch seems to indicate that the change was made within the 'if sys.platform[:3] == "win" ...:' block, which is where the advice doesn't apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470 From noreply at sourceforge.net Sat Jul 10 15:24:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 15:24:28 2004 Subject: [Patches] [ python-Patches-862531 ] installing modules are explained in old filenames Message-ID: Patches item #862531, was opened at 2003-12-18 15:24 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: installing modules are explained in old filenames Initial Comment: In the document of "Installing Python Modules", directory and file names are based on Python 2.0. For example: coff2omf python20.lib python20_bcpp.lib This patch is to change these version numbers up-to- date. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 08:24 Message: Logged In: YES user_id=2772 patch applies cleanly to cvs head "make pdf" still builds paper-letter/inst.pdf on my system after the patch I noticed two version-related problems in inst.tex after the patch: 2.4. The Start Menu instruction mentions version 2.1, and the interactive shell session is from 1.5.2 6.2. in the "coff2omf" line, only one "20" was changed to "24" 3.4. Should the MacOS 9 section be removed from the documentation? We aren't building for this OS anymore, I thought. I think this patch is worth including, but with the two items above fixed too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470 From noreply at sourceforge.net Sat Jul 10 15:24:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 15:24:55 2004 Subject: [Patches] [ python-Patches-862531 ] installing modules are explained in old filenames Message-ID: Patches item #862531, was opened at 2003-12-18 15:24 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: installing modules are explained in old filenames Initial Comment: In the document of "Installing Python Modules", directory and file names are based on Python 2.0. For example: coff2omf python20.lib python20_bcpp.lib This patch is to change these version numbers up-to- date. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 08:24 Message: Logged In: YES user_id=2772 patch applies cleanly to cvs head "make pdf" still builds paper-letter/inst.pdf on my system after the patch I noticed two version-related problems in inst.tex after the patch: 2.4. The Start Menu instruction mentions version 2.1, and the interactive shell session is from 1.5.2 6.2. in the "coff2omf" line, only one "20" was changed to "24" 3.4. Should the MacOS 9 section be removed from the documentation? We aren't building for this OS anymore, I thought. I think this patch is worth including, but with the two items above fixed too. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 08:24 Message: Logged In: YES user_id=2772 patch applies cleanly to cvs head "make pdf" still builds paper-letter/inst.pdf on my system after the patch I noticed two version-related problems in inst.tex after the patch: 2.4. The Start Menu instruction mentions version 2.1, and the interactive shell session is from 1.5.2 6.2. in the "coff2omf" line, only one "20" was changed to "24" 3.4. Should the MacOS 9 section be removed from the documentation? We aren't building for this OS anymore, I thought. I think this patch is worth including, but with the two items above fixed too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470 From noreply at sourceforge.net Sat Jul 10 15:47:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 15:47:54 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 13:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-07-10 23:47 Message: Logged In: YES user_id=14198 The point is to use a *new* distutils with an old Python version - ie, I want to use the latest distutils features to build a Python 1.5.2 distribution. OK, maybe not 1.5.2 anymore ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-10 21:36 Message: Logged In: YES user_id=21627 I'd like to mention that --target-version isn't really needed, IMO: it is relatively easy to just use the old Python executable to run setup.py, and it will automatically use the old distutils. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-07 05:23 Message: Logged In: YES user_id=11105 Ah, now I understand. I didn't even know that it was possible to use --target-version and --skip-build to build installers for other Python versions, but this is definitely cool. I checked in your patch to make sure it gets into 2.4a1. Your idea to specify an executable makes sense, but imo only when 2.4 is an old version, isn't it? Feel free to provide an additional patch for that, but I think one should still be able to use '2.3' as argument for the --target-version switch. BTW: The short variant of the --target-version switch (-v) conflicts with the --verbose option and doesn't work, so I'm taking this out as well. Checked in as bdist_wininst.py rev 1.49. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-02 09:19 Message: Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-02 05:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-02 05:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Sat Jul 10 16:13:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 16:13:18 2004 Subject: [Patches] [ python-Patches-987052 ] cgitb: escape title of page Message-ID: Patches item #987052, was opened at 2004-07-08 02:36 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987052&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thomas Guettler (guettli) >Assigned to: A.M. Kuchling (akuchling) Summary: cgitb: escape title of page Initial Comment: Here is a patch to cgitb.py. It escapes the header of the page. And removes

before

(tidy complains). The patch is against $Revision: 1.13 $ ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 10:13 Message: Logged In: YES user_id=11375 The patch looks good; applied to CVS HEAD. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=987052&group_id=5470 From noreply at sourceforge.net Sat Jul 10 16:18:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 16:18:51 2004 Subject: [Patches] [ python-Patches-982665 ] add SO_EXCLUSIVEADDRUSE constant in socketmodule.c Message-ID: Patches item #982665, was opened at 2004-06-30 06:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982665&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Garth Bushell (garth42) >Assigned to: A.M. Kuchling (akuchling) Summary: add SO_EXCLUSIVEADDRUSE constant in socketmodule.c Initial Comment: SO_REUSEADDR is has different meaning on windows to most socket implementations. It alows multiple programs to bind to the same address/port. This can cause very wierd bugs if two programs are used at the same time. (see http://www.itamarst.org/writings/win32sockets.html) Adding SO_EXCLUSIVEADDRUSE constant allows windows programmers to have the same semantics as unix ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 10:18 Message: Logged In: YES user_id=11375 Seems reasonable; checked into CVS HEAD. Thanks! ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-06-30 06:55 Message: Logged In: YES user_id=45280 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=982665&group_id=5470 From noreply at sourceforge.net Sat Jul 10 17:28:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 17:28:50 2004 Subject: [Patches] [ python-Patches-988504 ] urllib2.AbstractHTTPHandler broken Message-ID: Patches item #988504, was opened at 2004-07-10 16:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988504&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.AbstractHTTPHandler broken Initial Comment: urllib2.AbstractHTTPHandler lost half of a change that went in with patch 852995 in 1.57. The attached patch fixes it again. Jeremy removed half of that change in 1.63. Looks like he mistakenly thought it was a bug he introduced in 1.59. In fact, the change introduced in 1.63 broke HTTP error handling. To reproduce the bug, run the tests at the end of urllib2.py The issue is that AbstractHTTPHandler no longer handles HTTP errors. HTTPErrorProcessor does that now. Seems nobody remembers to run those tests. I wonder again whether at least some of them should live in the main test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988504&group_id=5470 From noreply at sourceforge.net Sat Jul 10 17:29:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 17:29:34 2004 Subject: [Patches] [ python-Patches-988504 ] urllib2.AbstractHTTPHandler broken Message-ID: Patches item #988504, was opened at 2004-07-10 16:28 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988504&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.AbstractHTTPHandler broken Initial Comment: urllib2.AbstractHTTPHandler lost half of a change that went in with patch 852995 in 1.57. The attached patch fixes it again. Jeremy removed half of that change in 1.63. Looks like he mistakenly thought it was a bug he introduced in 1.59. In fact, the change introduced in 1.63 broke HTTP error handling. To reproduce the bug, run the tests at the end of urllib2.py The issue is that AbstractHTTPHandler no longer handles HTTP errors. HTTPErrorProcessor does that now. Seems nobody remembers to run those tests. I wonder again whether at least some of them should live in the main test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988504&group_id=5470 From noreply at sourceforge.net Sat Jul 10 17:35:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 17:36:10 2004 Subject: [Patches] [ python-Patches-988504 ] urllib2.AbstractHTTPHandler broken Message-ID: Patches item #988504, was opened at 2004-07-10 11:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988504&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: John J Lee (jjlee) >Assigned to: A.M. Kuchling (akuchling) Summary: urllib2.AbstractHTTPHandler broken Initial Comment: urllib2.AbstractHTTPHandler lost half of a change that went in with patch 852995 in 1.57. The attached patch fixes it again. Jeremy removed half of that change in 1.63. Looks like he mistakenly thought it was a bug he introduced in 1.59. In fact, the change introduced in 1.63 broke HTTP error handling. To reproduce the bug, run the tests at the end of urllib2.py The issue is that AbstractHTTPHandler no longer handles HTTP errors. HTTPErrorProcessor does that now. Seems nobody remembers to run those tests. I wonder again whether at least some of them should live in the main test suite. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 11:35 Message: Logged In: YES user_id=11375 Checked into CVS HEAD; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988504&group_id=5470 From noreply at sourceforge.net Sat Jul 10 17:52:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 17:52:42 2004 Subject: [Patches] [ python-Patches-982681 ] asyncore.dispatcher.set_reuse_addr() is broken on windows Message-ID: Patches item #982681, was opened at 2004-06-30 07:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Garth Bushell (garth42) >Assigned to: A.M. Kuchling (akuchling) Summary: asyncore.dispatcher.set_reuse_addr() is broken on windows Initial Comment: asyncore.dispatcher.set_reuse_addr() uses socket.SO_REUSEADDR to allow reuse of same address without having to wait. On windows this also allows multiple programs to bind to the same socket adress. What is probably needed is to use SO_EXCLUSIVEADDRUSE on windows which has the same meaning as SO_REUSEADDR on all other platforms. This will stop people running the server multiple times and getting wierd results or two programs sharing the same port without realising. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 11:52 Message: Logged In: YES user_id=11375 Checked into CVS; thanks. ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-06-30 07:14 Message: Logged In: YES user_id=45280 this depends on patch #982665 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470 From noreply at sourceforge.net Sat Jul 10 19:04:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 19:04:50 2004 Subject: [Patches] [ python-Patches-851752 ] urllib2 silently returns None when auth_uri is mismatched Message-ID: Patches item #851752, was opened at 2003-11-30 16:16 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851752&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 silently returns None when auth_uri is mismatched Initial Comment: Fix for 820583. Also clarifies what install_opener does, since people often seem confused about this. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 12:04 Message: Logged In: YES user_id=2772 This patch looks right, and seems to describe the actual behavior. I can't build the lib documentation to test the patch, however ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851752&group_id=5470 From noreply at sourceforge.net Sat Jul 10 19:18:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 19:18:51 2004 Subject: [Patches] [ python-Patches-648322 ] asyncore loop_once and remove poll2 Message-ID: Patches item #648322, was opened at 2002-12-04 05:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648322&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kjetil Jacobsen (kjetilja) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore loop_once and remove poll2 Initial Comment: this patch does two things to asyncore.py, none of them should break any existing code which uses the module: 1) remove the (broken) poll2 function, and rather make a reference from poll2 to poll3 in the module namespace (i.e. if someone actually uses the poll2 function, poll3 will be called instead). 2) add a function loop_once which performs the asyncore loop once instead of until the socket map is empty. asyncore.loop_once has the same function signature as asyncore.loop. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 13:18 Message: Logged In: YES user_id=11375 loop() now takes an optional 'count' parameter, so this patch can now be closed. Thanks for submitting it! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-22 10:40 Message: Logged In: YES user_id=11375 Partially checked in; the existing poll2() implementation has been removed in rev.1.43 in CVS. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-22 10:28 Message: Logged In: YES user_id=11375 poll2() is written for a "poll" extension module that came with the Medusa distribution, so it'll never be used with a Python installation and poll2() can be safely removed. I'm less enthusiastic about loop_once(). Existing code that needs to loop once has been simply calling asyncore.poll(), which works fine (though perhaps suboptimally -- but 99% of asyncore applications won't care). ---------------------------------------------------------------------- Comment By: Kjetil Jacobsen (kjetilja) Date: 2002-12-05 13:46 Message: Logged In: YES user_id=5685 asyncore.poll2 is broken because it does not mask the EINTR exception when invoking the poll.poll function. this causes asyncore.poll2 to not have the same semantics as asyncore.poll and asyncore.poll3. i don't see the point in preserving support for the poll2 function, as the poll function is now automatically a part of the select module if the system has poll support. or am i missing something obvious here? :) if use_poll is set and there is no poll on the system, asyncore.loop and asyncore.loop_once will fail the same way they did before. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-05 11:49 Message: Logged In: YES user_id=21627 Can you please explain in what way poll2 is broken? Also, what happens if use_poll is set, but there is no poll available on the system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648322&group_id=5470 From noreply at sourceforge.net Sat Jul 10 20:28:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 20:28:36 2004 Subject: [Patches] [ python-Patches-972310 ] urllib2 handler algorithm docs Message-ID: Patches item #972310, was opened at 2004-06-13 18:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972310&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: John J Lee (jjlee) Assigned to: Martin v. L?wis (loewis) Summary: urllib2 handler algorithm docs Initial Comment: In adding the docs that explain how handler methods are called, I got the algorithm wrong. (I accidentally described the slightly different algorithm used by my urllib2-workalike module) This patch fixes that. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 14:28 Message: Logged In: YES user_id=11375 Applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972310&group_id=5470 From noreply at sourceforge.net Sat Jul 10 20:32:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 20:32:38 2004 Subject: [Patches] [ python-Patches-969907 ] Don't print to stdout in cookielib.py exception handler Message-ID: Patches item #969907, was opened at 2004-06-09 17:09 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: John J Lee (jjlee) Assigned to: Martin v. L?wis (loewis) Summary: Don't print to stdout in cookielib.py exception handler Initial Comment: There are a couple of blanket except: statements in cookielib. The idea is to handle any bugs in cookielib's input handling that may be tickled by unexpected input by issuing a warning instead of letting the exception propagate. Previously, in addition to issuing a warning, a traceback was printed. This patch makes the traceback part of the warning, so it can be suppressed. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 14:32 Message: Logged In: YES user_id=11375 Applied to CVS; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969907&group_id=5470 From noreply at sourceforge.net Sat Jul 10 20:40:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 20:40:16 2004 Subject: [Patches] [ python-Patches-969900 ] cookielib doc minor corrections and clarifications Message-ID: Patches item #969900, was opened at 2004-06-09 16:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969900&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: John J Lee (jjlee) Assigned to: Martin v. L?wis (loewis) Summary: cookielib doc minor corrections and clarifications Initial Comment: Nothing to add to the summary... ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 14:40 Message: Logged In: YES user_id=11375 Applied to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=969900&group_id=5470 From noreply at sourceforge.net Sat Jul 10 21:12:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 21:12:22 2004 Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket not working at all Message-ID: Patches item #945642, was opened at 2004-04-30 18:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tino Lange (tinolange) Assigned to: Nobody/Anonymous (nobody) Summary: nonblocking i/o with ssl socket not working at all Initial Comment: Hi! Unfortunately the applied patches #675750 and #676472 (End of January by G. Talvola / B. Laurie / G. v. Rossum) for timeout-sockets in version 1.09 and 1.10 to Modules/_ssl.c broke the nonblocking SSL I/O. In fact sslobj.read() became *always* blocking - whether the underlying socket is blocking or nonblocking doesn't matter at all. In Python < 2.3 this has worked correctly, starting with 2.3, 2.3.x up to the current CVS it doesn't work anymore. Attached is a sample: 0) [ Preparation ] Please run stunnel on your machine to have a SSL service: /usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712 1) [ Server ] Please run the easy server.py 2) [Client showing the bug] Please run the client - and see how it hangs when you use Python2.3. Also attached is a diff against the current _ssl.c which shows how to correct that behaviour while also having the possibilities from the above timeout patches. I carefully tested it, please review and test yourself and finally check-in. If you have questions, please don't hesitate to ask me. I really would like to see that not only in 2.4, but also (if possible together with patch #909007 from S. Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at all able to handle nonblocking SSL connections properly. Thanks and cheers, Tino ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 15:12 Message: Logged In: YES user_id=11375 The test programs don't work for me, either with or without the patch. They both crash with 'error:140770FC:SSL routines: SSL23_GET_SERVER_HELLO:unknown protocol'. What should I be seeing? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-11 18:20 Message: Logged In: YES user_id=212920 OK. Fine :-) Please find below in file "patch_honoring_the_style_guide.diff" an slightly changed version of my original patch that follows the PEP7 better (for the single else statements containg only one commad without parantheses) - but still honors the rest of the file also. Only the formatting has changed a little bit, no content. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-11 13:17 Message: Logged In: YES user_id=357491 The way you showed it, Tino, is correct. And I didn't realize the file was not following the spec. At this point, though, since we are trying to get someone to check this in before 2.3.4 goes out the door I wouldn't worry about it too much. Going in and fixing the syntax afterwards is not a huge deal. So if you have the time, great. Otherwise, because we have this possible time constraint and whom ever wrote the file in the first place didn't follow it, I wouldn't not worry about it too much. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-11 03:53 Message: Logged In: YES user_id=212920 Thanks for the hint. I guess --in the context of _ssl.c -- you only complain about the lines: } else sockstate = SOCKET_OPERATION_OK; or? Is that right? I think all the other else's are consistent - at least with the rest of the file - and some others I looked into (for example _bsddb.c). Or do you think that I shall reformat all the other else's in the file? Also those that are not from me? Really following the PEP it should look like: if (foo) { ... } else if (otherfoo) { ... } else { ... } instead of if (foo) { ... } else if (otherfoo) { ... } else { ... } everywhere, or? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-10 21:10 Message: Logged In: YES user_id=357491 A style nit: put 'else' statements on their own line. See PEP 7 (http:// www.python.org/peps/pep-0007.html) on C code guidelines. But I am no network programmer so I have no clue if the solution is good. ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-03 14:14 Message: Logged In: YES user_id=1033524 Hi Tino. I'll take your word for it. I though your ssl was based on the included SocketServer.py Cheers JJ ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-02 04:40 Message: Logged In: YES user_id=212920 Hi JJ, I just scanned your SocketServer.py - and I really don't see how this class might help? You don't offer a better sslob.read() there, don't you? So how could it help (besides maybe making my example "server.py nicer). If I put a sslobj on top of a socket object it is blocking in 2.3, 2.3.x and higher. As proven in my example: Making the underlying socket nonblocking has no effect - because SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE from the SSL_xxx() functions in the C-Library do not break out of the while loop that was introduced in the above mentioned patches. Cheers, Tino ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-01 22:46 Message: Logged In: YES user_id=1033524 Hi Tino. I just submitted a nonblocking SocketServer.py, it might just solve your problem. JJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 From noreply at sourceforge.net Sat Jul 10 21:39:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 21:39:42 2004 Subject: [Patches] [ python-Patches-988607 ] Fix for bug 980327 Message-ID: Patches item #988607, was opened at 2004-07-10 20:39 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=988607&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug 980327 Initial Comment: Bug 980327 reports a problem in ntpath.py, normpath. This patch fixes it, as far as I can tell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988607&group_id=5470 From noreply at sourceforge.net Sat Jul 10 21:55:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 21:55:53 2004 Subject: [Patches] [ python-Patches-988607 ] Fix for bug 980327 Message-ID: Patches item #988607, was opened at 2004-07-10 20:39 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988607&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug 980327 Initial Comment: Bug 980327 reports a problem in ntpath.py, normpath. This patch fixes it, as far as I can tell. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2004-07-10 20:55 Message: Logged In: YES user_id=113328 Just added a patch for the test suite. Note that the current suite had 3 tests which explicitly validated that the old behaviour was correct - but stated that this was "dubious". I've changed these old tests to match the new behaviour as well as adding 2 new tests specifically for this behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988607&group_id=5470 From noreply at sourceforge.net Sat Jul 10 21:59:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 22:00:04 2004 Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket not working at all Message-ID: Patches item #945642, was opened at 2004-05-01 00:14 Message generated for change (Comment added) made by tinolange You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tino Lange (tinolange) Assigned to: Nobody/Anonymous (nobody) Summary: nonblocking i/o with ssl socket not working at all Initial Comment: Hi! Unfortunately the applied patches #675750 and #676472 (End of January by G. Talvola / B. Laurie / G. v. Rossum) for timeout-sockets in version 1.09 and 1.10 to Modules/_ssl.c broke the nonblocking SSL I/O. In fact sslobj.read() became *always* blocking - whether the underlying socket is blocking or nonblocking doesn't matter at all. In Python < 2.3 this has worked correctly, starting with 2.3, 2.3.x up to the current CVS it doesn't work anymore. Attached is a sample: 0) [ Preparation ] Please run stunnel on your machine to have a SSL service: /usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712 1) [ Server ] Please run the easy server.py 2) [Client showing the bug] Please run the client - and see how it hangs when you use Python2.3. Also attached is a diff against the current _ssl.c which shows how to correct that behaviour while also having the possibilities from the above timeout patches. I carefully tested it, please review and test yourself and finally check-in. If you have questions, please don't hesitate to ask me. I really would like to see that not only in 2.4, but also (if possible together with patch #909007 from S. Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at all able to handle nonblocking SSL connections properly. Thanks and cheers, Tino ---------------------------------------------------------------------- >Comment By: Tino Lange (tinolange) Date: 2004-07-10 21:59 Message: Logged In: YES user_id=212920 Hi! Did you really start stunnel? It fakes the server.py LISTEN on 4712 as ssl service listening on 4711. I have stunnel 3.22 here. The options on 4.x might be completely different. You should see: 1) stunnel tino@tinont:$ /usr/sbin/stunnel -p /path/to/some.cert -f -d 4711 -r 4712 2004.07.10 21:49:56 LOG5[6518:1024]: Using '4712' as tcpwrapper service name 2004.07.10 21:49:56 LOG5[6518:1024]: stunnel 3.22 on i586-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.6c 21 dec 2001 2004.07.10 21:49:56 LOG5[6518:1024]: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed 2) server.py tino@tinont:$ python server.py server is waiting for client connection on port 4712! 3) client.py a) python 2.1 tino@tinont:$ python client.py SSL Issuer: '...' SSL Server: '...' ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'Hallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## Hallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall' ... going to read from sslobj ... read 'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal' ... going to read from sslobj ... read 'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa' ... going to read from sslobj ... read 'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH' ... going to read from sslobj ... read 'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read '' ## SSL Socket: Counterpart has closed the connection ## tino@tinont:$ b) python 2.3.x or 2.4 tino@tinont:$ python2.3 client.py SSL Issuer: '...' SSL Server: '...' ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'Hallo ' ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall' ... going to read from sslobj ... read 'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal' ... going to read from sslobj ... read 'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa' ... going to read from sslobj ... read 'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH' ... going to read from sslobj ... read 'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (6): 'TLS/SSL connection has been closed' ## Hallo HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ## SSL Socket: Counterpart has closed the connection ## tino@tinont:$ As you can see the client.py completely blocks while the server is sleeping between sending some data when using python 2.3.x or 2.4. In 2.1 and 2.2 the client.py returns as expected for a nonblocking client in between - and select tells us when we can continue reading. Hope this helps Tino ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 21:12 Message: Logged In: YES user_id=11375 The test programs don't work for me, either with or without the patch. They both crash with 'error:140770FC:SSL routines: SSL23_GET_SERVER_HELLO:unknown protocol'. What should I be seeing? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-12 00:20 Message: Logged In: YES user_id=212920 OK. Fine :-) Please find below in file "patch_honoring_the_style_guide.diff" an slightly changed version of my original patch that follows the PEP7 better (for the single else statements containg only one commad without parantheses) - but still honors the rest of the file also. Only the formatting has changed a little bit, no content. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-11 19:17 Message: Logged In: YES user_id=357491 The way you showed it, Tino, is correct. And I didn't realize the file was not following the spec. At this point, though, since we are trying to get someone to check this in before 2.3.4 goes out the door I wouldn't worry about it too much. Going in and fixing the syntax afterwards is not a huge deal. So if you have the time, great. Otherwise, because we have this possible time constraint and whom ever wrote the file in the first place didn't follow it, I wouldn't not worry about it too much. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-11 09:53 Message: Logged In: YES user_id=212920 Thanks for the hint. I guess --in the context of _ssl.c -- you only complain about the lines: } else sockstate = SOCKET_OPERATION_OK; or? Is that right? I think all the other else's are consistent - at least with the rest of the file - and some others I looked into (for example _bsddb.c). Or do you think that I shall reformat all the other else's in the file? Also those that are not from me? Really following the PEP it should look like: if (foo) { ... } else if (otherfoo) { ... } else { ... } instead of if (foo) { ... } else if (otherfoo) { ... } else { ... } everywhere, or? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-11 03:10 Message: Logged In: YES user_id=357491 A style nit: put 'else' statements on their own line. See PEP 7 (http:// www.python.org/peps/pep-0007.html) on C code guidelines. But I am no network programmer so I have no clue if the solution is good. ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-03 20:14 Message: Logged In: YES user_id=1033524 Hi Tino. I'll take your word for it. I though your ssl was based on the included SocketServer.py Cheers JJ ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-02 10:40 Message: Logged In: YES user_id=212920 Hi JJ, I just scanned your SocketServer.py - and I really don't see how this class might help? You don't offer a better sslob.read() there, don't you? So how could it help (besides maybe making my example "server.py nicer). If I put a sslobj on top of a socket object it is blocking in 2.3, 2.3.x and higher. As proven in my example: Making the underlying socket nonblocking has no effect - because SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE from the SSL_xxx() functions in the C-Library do not break out of the while loop that was introduced in the above mentioned patches. Cheers, Tino ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-02 04:46 Message: Logged In: YES user_id=1033524 Hi Tino. I just submitted a nonblocking SocketServer.py, it might just solve your problem. JJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 From noreply at sourceforge.net Sat Jul 10 22:05:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 22:05:27 2004 Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket not working at all Message-ID: Patches item #945642, was opened at 2004-05-01 00:14 Message generated for change (Comment added) made by tinolange You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tino Lange (tinolange) Assigned to: Nobody/Anonymous (nobody) Summary: nonblocking i/o with ssl socket not working at all Initial Comment: Hi! Unfortunately the applied patches #675750 and #676472 (End of January by G. Talvola / B. Laurie / G. v. Rossum) for timeout-sockets in version 1.09 and 1.10 to Modules/_ssl.c broke the nonblocking SSL I/O. In fact sslobj.read() became *always* blocking - whether the underlying socket is blocking or nonblocking doesn't matter at all. In Python < 2.3 this has worked correctly, starting with 2.3, 2.3.x up to the current CVS it doesn't work anymore. Attached is a sample: 0) [ Preparation ] Please run stunnel on your machine to have a SSL service: /usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712 1) [ Server ] Please run the easy server.py 2) [Client showing the bug] Please run the client - and see how it hangs when you use Python2.3. Also attached is a diff against the current _ssl.c which shows how to correct that behaviour while also having the possibilities from the above timeout patches. I carefully tested it, please review and test yourself and finally check-in. If you have questions, please don't hesitate to ask me. I really would like to see that not only in 2.4, but also (if possible together with patch #909007 from S. Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at all able to handle nonblocking SSL connections properly. Thanks and cheers, Tino ---------------------------------------------------------------------- >Comment By: Tino Lange (tinolange) Date: 2004-07-10 22:05 Message: Logged In: YES user_id=212920 BTW: >From reading the Bug Summary I think that applying this patch will also fix Bug #977680. Please test afterwards. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 21:59 Message: Logged In: YES user_id=212920 Hi! Did you really start stunnel? It fakes the server.py LISTEN on 4712 as ssl service listening on 4711. I have stunnel 3.22 here. The options on 4.x might be completely different. You should see: 1) stunnel tino@tinont:$ /usr/sbin/stunnel -p /path/to/some.cert -f -d 4711 -r 4712 2004.07.10 21:49:56 LOG5[6518:1024]: Using '4712' as tcpwrapper service name 2004.07.10 21:49:56 LOG5[6518:1024]: stunnel 3.22 on i586-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.6c 21 dec 2001 2004.07.10 21:49:56 LOG5[6518:1024]: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed 2) server.py tino@tinont:$ python server.py server is waiting for client connection on port 4712! 3) client.py a) python 2.1 tino@tinont:$ python client.py SSL Issuer: '...' SSL Server: '...' ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'Hallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## Hallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall' ... going to read from sslobj ... read 'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal' ... going to read from sslobj ... read 'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa' ... going to read from sslobj ... read 'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH' ... going to read from sslobj ... read 'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read '' ## SSL Socket: Counterpart has closed the connection ## tino@tinont:$ b) python 2.3.x or 2.4 tino@tinont:$ python2.3 client.py SSL Issuer: '...' SSL Server: '...' ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'Hallo ' ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall' ... going to read from sslobj ... read 'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal' ... going to read from sslobj ... read 'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa' ... going to read from sslobj ... read 'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH' ... going to read from sslobj ... read 'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (6): 'TLS/SSL connection has been closed' ## Hallo HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ## SSL Socket: Counterpart has closed the connection ## tino@tinont:$ As you can see the client.py completely blocks while the server is sleeping between sending some data when using python 2.3.x or 2.4. In 2.1 and 2.2 the client.py returns as expected for a nonblocking client in between - and select tells us when we can continue reading. Hope this helps Tino ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 21:12 Message: Logged In: YES user_id=11375 The test programs don't work for me, either with or without the patch. They both crash with 'error:140770FC:SSL routines: SSL23_GET_SERVER_HELLO:unknown protocol'. What should I be seeing? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-12 00:20 Message: Logged In: YES user_id=212920 OK. Fine :-) Please find below in file "patch_honoring_the_style_guide.diff" an slightly changed version of my original patch that follows the PEP7 better (for the single else statements containg only one commad without parantheses) - but still honors the rest of the file also. Only the formatting has changed a little bit, no content. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-11 19:17 Message: Logged In: YES user_id=357491 The way you showed it, Tino, is correct. And I didn't realize the file was not following the spec. At this point, though, since we are trying to get someone to check this in before 2.3.4 goes out the door I wouldn't worry about it too much. Going in and fixing the syntax afterwards is not a huge deal. So if you have the time, great. Otherwise, because we have this possible time constraint and whom ever wrote the file in the first place didn't follow it, I wouldn't not worry about it too much. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-11 09:53 Message: Logged In: YES user_id=212920 Thanks for the hint. I guess --in the context of _ssl.c -- you only complain about the lines: } else sockstate = SOCKET_OPERATION_OK; or? Is that right? I think all the other else's are consistent - at least with the rest of the file - and some others I looked into (for example _bsddb.c). Or do you think that I shall reformat all the other else's in the file? Also those that are not from me? Really following the PEP it should look like: if (foo) { ... } else if (otherfoo) { ... } else { ... } instead of if (foo) { ... } else if (otherfoo) { ... } else { ... } everywhere, or? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-11 03:10 Message: Logged In: YES user_id=357491 A style nit: put 'else' statements on their own line. See PEP 7 (http:// www.python.org/peps/pep-0007.html) on C code guidelines. But I am no network programmer so I have no clue if the solution is good. ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-03 20:14 Message: Logged In: YES user_id=1033524 Hi Tino. I'll take your word for it. I though your ssl was based on the included SocketServer.py Cheers JJ ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-02 10:40 Message: Logged In: YES user_id=212920 Hi JJ, I just scanned your SocketServer.py - and I really don't see how this class might help? You don't offer a better sslob.read() there, don't you? So how could it help (besides maybe making my example "server.py nicer). If I put a sslobj on top of a socket object it is blocking in 2.3, 2.3.x and higher. As proven in my example: Making the underlying socket nonblocking has no effect - because SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE from the SSL_xxx() functions in the C-Library do not break out of the while loop that was introduced in the above mentioned patches. Cheers, Tino ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-02 04:46 Message: Logged In: YES user_id=1033524 Hi Tino. I just submitted a nonblocking SocketServer.py, it might just solve your problem. JJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 From noreply at sourceforge.net Sat Jul 10 22:50:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 22:51:00 2004 Subject: [Patches] [ python-Patches-988607 ] Fix for bug 980327 Message-ID: Patches item #988607, was opened at 2004-07-10 12:39 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988607&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug 980327 Initial Comment: Bug 980327 reports a problem in ntpath.py, normpath. This patch fixes it, as far as I can tell. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-10 13:50 Message: Logged In: YES user_id=357491 For Python 2.4.a2 rev. 1.60 and rev. 1.19 patch Lib/ntpath.py and Lib/ test/test_ntpath.py . For Python 2.3.5, rev. 1.57.10.2 and rev. 1.18.16.1 do the trick. Thanks, Paul. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-07-10 12:55 Message: Logged In: YES user_id=113328 Just added a patch for the test suite. Note that the current suite had 3 tests which explicitly validated that the old behaviour was correct - but stated that this was "dubious". I've changed these old tests to match the new behaviour as well as adding 2 new tests specifically for this behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988607&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:07:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:07:52 2004 Subject: [Patches] [ python-Patches-637217 ] inspect.getargspec: None instead of () Message-ID: Patches item #637217, was opened at 2002-11-12 08:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=637217&group_id=5470 >Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nathan Srebro (nati) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec: None instead of () Initial Comment: When a function has no default arguments, getargspec (in module inspec) returns a fourth return-value of None: >>> inspect.getargspec(lambda x:x) (['x'], None, None, None) According to the documentation, the fourth return value, defaults, "is a tuple of default argument values; if this tuple has n elements, they correspond to the last n elements listed in args.". This suggests that if there are no default arguments, an empty tuple should be returned. This is also more consistent. Returning None requires special handling in code using this return value. Attached is a corrected version of getargspec (a check for 'defaults is None' is added). (This bug exists in both 2.2.2 and the current CVS) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-10 14:07 Message: Logged In: YES user_id=357491 I am rejecting the bug itself for the sole reason that it has been this way for ages and changing it now might break code. But having it return None instead of () is not that big of a deal: just have the test be ``not inspect.gerargspec(lambda x:x)[3]`` instead of specifying you are checking for an empty tuple which is just more Pythonic and better practice anyway. I did clarify the docs to say None is returned when there are no default arguments. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 19:27 Message: Logged In: YES user_id=357491 Making this a patch since it has code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=637217&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:16:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:16:12 2004 Subject: [Patches] [ python-Patches-988642 ] Update HTTPRespnse.length Message-ID: Patches item #988642, was opened at 2004-07-10 21: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=988642&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Update HTTPRespnse.length Initial Comment: Update length attribute correctly when read() returns less than the expected number of bytes. Addresses bug # 988120 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:17:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:17:53 2004 Subject: [Patches] [ python-Patches-988643 ] Untested fix for 988120 Message-ID: Patches item #988643, was opened at 2004-07-10 22:17 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=988643&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Untested fix for 988120 Initial Comment: Nothing to add to summary... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988643&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:21:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:21:36 2004 Subject: [Patches] [ python-Patches-909007 ] _ssl.c compatibility Message-ID: Patches item #909007, was opened at 2004-03-03 08:13 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909007&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samuel Nicolary (nicolary) >Assigned to: A.M. Kuchling (akuchling) Summary: _ssl.c compatibility Initial Comment: A simple addition to the _ssl.c module adds SSL compatibility for many known problematic SSL server implementations. See OpenSSL's SSL_CTX_set_options manpage for further details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909007&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:23:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:23:22 2004 Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket not working at all Message-ID: Patches item #945642, was opened at 2004-04-30 18:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Tino Lange (tinolange) >Assigned to: A.M. Kuchling (akuchling) Summary: nonblocking i/o with ssl socket not working at all Initial Comment: Hi! Unfortunately the applied patches #675750 and #676472 (End of January by G. Talvola / B. Laurie / G. v. Rossum) for timeout-sockets in version 1.09 and 1.10 to Modules/_ssl.c broke the nonblocking SSL I/O. In fact sslobj.read() became *always* blocking - whether the underlying socket is blocking or nonblocking doesn't matter at all. In Python < 2.3 this has worked correctly, starting with 2.3, 2.3.x up to the current CVS it doesn't work anymore. Attached is a sample: 0) [ Preparation ] Please run stunnel on your machine to have a SSL service: /usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712 1) [ Server ] Please run the easy server.py 2) [Client showing the bug] Please run the client - and see how it hangs when you use Python2.3. Also attached is a diff against the current _ssl.c which shows how to correct that behaviour while also having the possibilities from the above timeout patches. I carefully tested it, please review and test yourself and finally check-in. If you have questions, please don't hesitate to ask me. I really would like to see that not only in 2.4, but also (if possible together with patch #909007 from S. Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at all able to handle nonblocking SSL connections properly. Thanks and cheers, Tino ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 17:23 Message: Logged In: YES user_id=11375 Committed to CVS head; thanks for all your work! ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 16:05 Message: Logged In: YES user_id=212920 BTW: >From reading the Bug Summary I think that applying this patch will also fix Bug #977680. Please test afterwards. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 15:59 Message: Logged In: YES user_id=212920 Hi! Did you really start stunnel? It fakes the server.py LISTEN on 4712 as ssl service listening on 4711. I have stunnel 3.22 here. The options on 4.x might be completely different. You should see: 1) stunnel tino@tinont:$ /usr/sbin/stunnel -p /path/to/some.cert -f -d 4711 -r 4712 2004.07.10 21:49:56 LOG5[6518:1024]: Using '4712' as tcpwrapper service name 2004.07.10 21:49:56 LOG5[6518:1024]: stunnel 3.22 on i586-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.6c 21 dec 2001 2004.07.10 21:49:56 LOG5[6518:1024]: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed 2) server.py tino@tinont:$ python server.py server is waiting for client connection on port 4712! 3) client.py a) python 2.1 tino@tinont:$ python client.py SSL Issuer: '...' SSL Server: '...' ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'Hallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## Hallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall' ... going to read from sslobj ... read 'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal' ... going to read from sslobj ... read 'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa' ... going to read from sslobj ... read 'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH' ... going to read from sslobj ... read 'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (11): 'Resource temporarily unavailable' ## HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [] ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read '' ## SSL Socket: Counterpart has closed the connection ## tino@tinont:$ b) python 2.3.x or 2.4 tino@tinont:$ python2.3 client.py SSL Issuer: '...' SSL Server: '...' ... selecting, readset = [3], timeout = 1.0 ... returning from select - r = [3] ... something to read from socket/ssl has arrived! ... going to read from sslobj ... read 'Hallo ' ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... read 'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall' ... going to read from sslobj ... read 'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal' ... going to read from sslobj ... read 'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa' ... going to read from sslobj ... read 'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH' ... going to read from sslobj ... read 'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ' ... going to read from sslobj ... (ignored) ## SSL Socket Error (6): 'TLS/SSL connection has been closed' ## Hallo HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo ## SSL Socket: Counterpart has closed the connection ## tino@tinont:$ As you can see the client.py completely blocks while the server is sleeping between sending some data when using python 2.3.x or 2.4. In 2.1 and 2.2 the client.py returns as expected for a nonblocking client in between - and select tells us when we can continue reading. Hope this helps Tino ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 15:12 Message: Logged In: YES user_id=11375 The test programs don't work for me, either with or without the patch. They both crash with 'error:140770FC:SSL routines: SSL23_GET_SERVER_HELLO:unknown protocol'. What should I be seeing? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-11 18:20 Message: Logged In: YES user_id=212920 OK. Fine :-) Please find below in file "patch_honoring_the_style_guide.diff" an slightly changed version of my original patch that follows the PEP7 better (for the single else statements containg only one commad without parantheses) - but still honors the rest of the file also. Only the formatting has changed a little bit, no content. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-11 13:17 Message: Logged In: YES user_id=357491 The way you showed it, Tino, is correct. And I didn't realize the file was not following the spec. At this point, though, since we are trying to get someone to check this in before 2.3.4 goes out the door I wouldn't worry about it too much. Going in and fixing the syntax afterwards is not a huge deal. So if you have the time, great. Otherwise, because we have this possible time constraint and whom ever wrote the file in the first place didn't follow it, I wouldn't not worry about it too much. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-11 03:53 Message: Logged In: YES user_id=212920 Thanks for the hint. I guess --in the context of _ssl.c -- you only complain about the lines: } else sockstate = SOCKET_OPERATION_OK; or? Is that right? I think all the other else's are consistent - at least with the rest of the file - and some others I looked into (for example _bsddb.c). Or do you think that I shall reformat all the other else's in the file? Also those that are not from me? Really following the PEP it should look like: if (foo) { ... } else if (otherfoo) { ... } else { ... } instead of if (foo) { ... } else if (otherfoo) { ... } else { ... } everywhere, or? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-10 21:10 Message: Logged In: YES user_id=357491 A style nit: put 'else' statements on their own line. See PEP 7 (http:// www.python.org/peps/pep-0007.html) on C code guidelines. But I am no network programmer so I have no clue if the solution is good. ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-03 14:14 Message: Logged In: YES user_id=1033524 Hi Tino. I'll take your word for it. I though your ssl was based on the included SocketServer.py Cheers JJ ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-05-02 04:40 Message: Logged In: YES user_id=212920 Hi JJ, I just scanned your SocketServer.py - and I really don't see how this class might help? You don't offer a better sslob.read() there, don't you? So how could it help (besides maybe making my example "server.py nicer). If I put a sslobj on top of a socket object it is blocking in 2.3, 2.3.x and higher. As proven in my example: Making the underlying socket nonblocking has no effect - because SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE from the SSL_xxx() functions in the C-Library do not break out of the while loop that was introduced in the above mentioned patches. Cheers, Tino ---------------------------------------------------------------------- Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Date: 2004-05-01 22:46 Message: Logged In: YES user_id=1033524 Hi Tino. I just submitted a nonblocking SocketServer.py, it might just solve your problem. JJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:38:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:38:31 2004 Subject: [Patches] [ python-Patches-909007 ] _ssl.c compatibility Message-ID: Patches item #909007, was opened at 2004-03-03 08:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909007&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Samuel Nicolary (nicolary) Assigned to: A.M. Kuchling (akuchling) Summary: _ssl.c compatibility Initial Comment: A simple addition to the _ssl.c module adds SSL compatibility for many known problematic SSL server implementations. See OpenSSL's SSL_CTX_set_options manpage for further details. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 17:38 Message: Logged In: YES user_id=11375 This change seems uncontroversial, so I'm applying it to the CVS HEAD. Thanks for submitting it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909007&group_id=5470 From noreply at sourceforge.net Sat Jul 10 23:50:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 10 23:50:29 2004 Subject: [Patches] [ python-Patches-965175 ] improve markupbase.py error reporting Message-ID: Patches item #965175, was opened at 2004-06-02 12:59 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965175&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: No Spam (not4spam) Assigned to: A.M. Kuchling (akuchling) Summary: improve markupbase.py error reporting Initial Comment: This is just a minor nit, but in "_scan_name" in "markupbase.py" if it cannot find a name token, it just reports "expected name token" without any identifying information. This can be easily improved by changing the line (379) from, self.error("expected name token") to, self.error("expected name token at '%s'" % rawdata[declstartpos:declstartpos+20]) which will show 20 characters of text where the error occured. Perhaps this can be changed in version 2.4? Thanks. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 17:50 Message: Logged In: YES user_id=11375 Good suggestion; incorporated into the CVS HEAD (and hence Python 2.4). Thanks for the suggestion! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=965175&group_id=5470 From noreply at sourceforge.net Sun Jul 11 00:02:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 00:02:39 2004 Subject: [Patches] [ python-Patches-988444 ] tarfile.py and multiple extended headers Message-ID: Patches item #988444, was opened at 2004-07-10 07:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988444&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: A.M. Kuchling (akuchling) Summary: tarfile.py and multiple extended headers Initial Comment: At the moment, tarfile.py is only able to read one extended/special header (such as GNU longname etc.) at once from an archive. In some cases there may be more than one special header to process, e.g. an archive member that points to a long linkname itself having a long name, or a GNU sparse file member with a long name. In those cases tarfile.py will fail to read that particular member including all following ones. The attached patch fixes that problem plus some minor things that I came across while fixing it: - fixed/improved handling of extended/special headers in read-mode (adding new extended headers should be less painful now). - improved nts() function. - removed TarFile.chunks datastructure which is not (and was never) needed. - fixed TarInfo.tobuf(), fields could overflow with too large values, values are now clipped. The patch is made against 2.4a1 sources. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 18:02 Message: Logged In: YES user_id=11375 Applied to CVS HEAD; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988444&group_id=5470 From noreply at sourceforge.net Sun Jul 11 00:07:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 00:08:04 2004 Subject: [Patches] [ python-Patches-981794 ] webbrower support for firebird / firefox Message-ID: Patches item #981794, was opened at 2004-06-29 03:35 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981794&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thenault Sylvain (syt) >Assigned to: A.M. Kuchling (akuchling) Summary: webbrower support for firebird / firefox Initial Comment: this patch add detection of the mozilla firebird and firefox browser to the webbrowser module from the std lib ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 18:07 Message: Logged In: YES user_id=11375 Applied to CVS HEAD; thanks! ---------------------------------------------------------------------- Comment By: Thenault Sylvain (syt) Date: 2004-06-29 10:25 Message: Logged In: YES user_id=387525 with the patch attached... At least this time I've checked the checkbox. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 10:04 Message: Logged In: YES user_id=11375 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=981794&group_id=5470 From noreply at sourceforge.net Sun Jul 11 00:23:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 00:23:41 2004 Subject: [Patches] [ python-Patches-550732 ] PyArg_VaParseTupleAndKeywords Message-ID: Patches item #550732, was opened at 2002-04-30 11:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyArg_VaParseTupleAndKeywords Initial Comment: I need a Va version of PyArg_ParseTupleAndKeywords for some generic code where the number of expected arguments isn't known until runtime. Attached is a patch which adds a PyArg_VaParseTupleAndKeywords to getargs.c. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-10 15:23 Message: Logged In: YES user_id=357491 Committed for Python 2.4a2 for rev. 2.101 Python/getargs.c, rev. 2.41 for Include/modsupport.h, and rev. 1.16 for Doc/api/utilities.tex . ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-13 05:29 Message: Logged In: YES user_id=3066 This looks good to me; I can make the markup changes needed for the documentation patch. I'll try and get this in later today. A minimal test should probably be added to Modules/_testcapimodule.c, though there isn't much to test. That could be contributed as a separate patch. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-05-08 11:36 Message: Logged In: YES user_id=86307 I probably should have added that the patch is against the current CVS version of utilities.tex (1.4). I saved it from my web browser, so it has today's date rather than the date in the CVS. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-05-08 11:32 Message: Logged In: YES user_id=86307 I'm attaching a very minimal (possibly inadequate) doc patch for api/utilities.tex. I was going to model it after the documentation for PyArg_VaParse, but that doesn't exist, so I've provided some documentation for both PyArg_VaParse and PyArg_VaParseTupleAndKeywords. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 05:37 Message: Logged In: YES user_id=6380 Looks like a good idea to me. Needs a small API doc patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 From noreply at sourceforge.net Sun Jul 11 00:36:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 00:36:37 2004 Subject: [Patches] [ python-Patches-988642 ] Update HTTPRespnse.length Message-ID: Patches item #988642, was opened at 2004-07-10 22:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Update HTTPRespnse.length Initial Comment: Update length attribute correctly when read() returns less than the expected number of bytes. Addresses bug # 988120 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-10 23:36 Message: Logged In: YES user_id=261020 Patch basically looks good, but I'm worrying about the bit of code in the current httplib.py, in the block commented with '# unbounded read'. Why the switch on .will_close? Shouldn't the switch be on (self.length is None), instead? I could well be missing something, but this looks like another bug of the same kind as in the original report. Also, how about the various .readline() calls? Might they also return less than a full line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 From noreply at sourceforge.net Sun Jul 11 00:37:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 00:37:27 2004 Subject: [Patches] [ python-Patches-988643 ] Untested fix for 988120 Message-ID: Patches item #988643, was opened at 2004-07-10 22:17 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988643&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Untested fix for 988120 Initial Comment: Nothing to add to summary... ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2004-07-10 23:37 Message: Logged In: YES user_id=261020 Closing, since patch 988642 is better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988643&group_id=5470 From noreply at sourceforge.net Sun Jul 11 01:40:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 01:40:52 2004 Subject: [Patches] [ python-Patches-947352 ] AF_PACKET Hardware address support in socket module Message-ID: Patches item #947352, was opened at 2004-05-03 19:36 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Andryuk (thedeuce) Assigned to: Nobody/Anonymous (nobody) Summary: AF_PACKET Hardware address support in socket module Initial Comment: The current implementation of AF_PACKET only uses the device name and protocol options even when a 5-tuple of Device, Protocol, Packet Type, Hardware Type, and Hardware Address are supplied. I needed socket.sendto() to support sending to a Hardware Address, so this patch supports such functionality. The length check on the hardware address is hard coded to 8 since that is the value used in the sockaddr_ll struct. I'm not that familiar with the Python internals, so s->errorhandler() may not be the best call to make for an invalid hardware address length. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 19:40 Message: Logged In: YES user_id=11375 Checked in to CVS HEAD; thanks for the patch! I think s_errorhandler is only when you're trying to report the error from a system call; I changed to raise a ValueError if the hardware address is too long. Please give the CVS version a try and let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 From noreply at sourceforge.net Sun Jul 11 01:41:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 01:41:46 2004 Subject: [Patches] [ python-Patches-947352 ] AF_PACKET Hardware address support in socket module Message-ID: Patches item #947352, was opened at 2004-05-03 19:36 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Andryuk (thedeuce) >Assigned to: A.M. Kuchling (akuchling) Summary: AF_PACKET Hardware address support in socket module Initial Comment: The current implementation of AF_PACKET only uses the device name and protocol options even when a 5-tuple of Device, Protocol, Packet Type, Hardware Type, and Hardware Address are supplied. I needed socket.sendto() to support sending to a Hardware Address, so this patch supports such functionality. The length check on the hardware address is hard coded to 8 since that is the value used in the sockaddr_ll struct. I'm not that familiar with the Python internals, so s->errorhandler() may not be the best call to make for an invalid hardware address length. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 19:40 Message: Logged In: YES user_id=11375 Checked in to CVS HEAD; thanks for the patch! I think s_errorhandler is only when you're trying to report the error from a system call; I changed to raise a ValueError if the hardware address is too long. Please give the CVS version a try and let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 From noreply at sourceforge.net Sun Jul 11 01:44:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 01:44:48 2004 Subject: [Patches] [ python-Patches-988698 ] compiler.transformer fix for (a, b) = 1, 2 Message-ID: Patches item #988698, was opened at 2004-07-10 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=988698&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: compiler.transformer fix for (a, b) = 1, 2 Initial Comment: This fixes bug 988613 in the compiler.transformer. A mimimal unittest file will also be attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 From noreply at sourceforge.net Sun Jul 11 01:54:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 01:54:40 2004 Subject: [Patches] [ python-Patches-988698 ] compiler.transformer fix for (a, b) = 1, 2 Message-ID: Patches item #988698, was opened at 2004-07-10 16:44 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) >Assigned to: Jeremy Hylton (jhylton) Summary: compiler.transformer fix for (a, b) = 1, 2 Initial Comment: This fixes bug 988613 in the compiler.transformer. A mimimal unittest file will also be attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 From noreply at sourceforge.net Sun Jul 11 01:59:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 01:59:30 2004 Subject: [Patches] [ python-Patches-980120 ] difflib empty list IndexError fix (Bug #980117) Message-ID: Patches item #980120, was opened at 2004-06-25 19:52 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980120&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rocco Moretti (roccomoretti) Assigned to: Nobody/Anonymous (nobody) Summary: difflib empty list IndexError fix (Bug #980117) Initial Comment: This is a potential fix for the Bug #980117. The functions unified_diff() and context_diff() give an IndexError when called with two empty lists due to an unmasked index of the opcode lists in SequenceMatcher.get_grouped_opcodes(). In the case of two empty lists passed to the functions, SequenceMatcher.codes is an empty list. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-10 16:59 Message: Logged In: YES user_id=357491 Fixed in rev. 1.21 of Lib/difflib.py . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980120&group_id=5470 From noreply at sourceforge.net Sun Jul 11 02:02:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 02:02:32 2004 Subject: [Patches] [ python-Patches-988698 ] compiler.transformer fix for (a, b) = 1, 2 Message-ID: Patches item #988698, was opened at 2004-07-10 18:44 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Jeremy Hylton (jhylton) Summary: compiler.transformer fix for (a, b) = 1, 2 Initial Comment: This fixes bug 988613 in the compiler.transformer. A mimimal unittest file will also be attached. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 19:02 Message: Logged In: YES user_id=2772 This looks good to me. It's the same change as in Python/compile.c:com_assign_sequence() from version 2.302 http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/compile.c?r1=2.301&r2=2.302 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 From noreply at sourceforge.net Sun Jul 11 04:18:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 04:18:19 2004 Subject: [Patches] [ python-Patches-851752 ] urllib2 silently returns None when auth_uri is mismatched Message-ID: Patches item #851752, was opened at 2003-11-30 17:16 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851752&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Kurt B. Kaiser (kbk) Summary: urllib2 silently returns None when auth_uri is mismatched Initial Comment: Fix for 820583. Also clarifies what install_opener does, since people often seem confused about this. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-10 21:18 Message: Logged In: YES user_id=149084 builds OK. liburllib2.tex 1.20 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-10 12:04 Message: Logged In: YES user_id=2772 This patch looks right, and seems to describe the actual behavior. I can't build the lib documentation to test the patch, however ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851752&group_id=5470 From noreply at sourceforge.net Sun Jul 11 05:25:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 05:25:44 2004 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 22: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=988761&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Sun Jul 11 09:56:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 09:56:44 2004 Subject: [Patches] [ python-Patches-972991 ] fix build of docs in info format Message-ID: Patches item #972991, was opened at 2004-06-15 05:47 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: fix build of docs in info format Initial Comment: one of those a workaround in py2texi.el (verbatim environments are processed before comments) ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2004-07-11 07:56 Message: Logged In: YES user_id=60903 > need more documentation ??? - the libfuncs.tex patch fixes wrong latex. - the dist.tex patch avoid uncommenting the verbose environment by py2texi. ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-07-01 21:40 Message: Logged In: YES user_id=943591 need more documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 From noreply at sourceforge.net Sun Jul 11 19:15:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 19:15:47 2004 Subject: [Patches] [ python-Patches-972332 ] urllib2 FTPHandler bugs Message-ID: Patches item #972332, was opened at 2004-06-13 18:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972332&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Kurt B. Kaiser (kbk) Summary: urllib2 FTPHandler bugs Initial Comment: This uncomments a couple of failing tests in test_urllib2.py, and fixes the corresponding bugs: 1. The first bug was half-fixed since I wrote the test. Ports in FTP URLs are now correctly handled. However, the type of the port argument passed to ftplib.FTP.connect() is incorrect (is a string, should be an integer). 2. The ftp://example.com/foo.txt;type=a syntax is implemented but broken. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-11 12:15 Message: Logged In: YES user_id=149084 urllib2.py 1.72 test_urllib2.py 1.18 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972332&group_id=5470 From noreply at sourceforge.net Sun Jul 11 21:28:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 21:28:15 2004 Subject: [Patches] [ python-Patches-986010 ] add missing doc for datetime C API Message-ID: Patches item #986010, was opened at 2004-07-06 10:28 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add missing doc for datetime C API Initial Comment: Attached is the missing documentation for the accessor macros. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-11 15:28 Message: Logged In: YES user_id=31435 Thanks again, Anthony. I took the opportunity to rework the docs a bit more, to add some structure to the now-large pile of datetime macros. Doc/api/concrete.tex; new revision: 1.46 Misc/NEWS; new revision: 1.1038 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 From noreply at sourceforge.net Sun Jul 11 23:05:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 11 23:06:05 2004 Subject: [Patches] [ python-Patches-956394 ] imaplib.IMAP4_SSL: changed quadratic read() code to linear Message-ID: Patches item #956394, was opened at 2004-05-19 03:15 Message generated for change (Comment added) made by tinolange You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=956394&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Carl Howells (c_wraith) Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4_SSL: changed quadratic read() code to linear Initial Comment: read() in imaplib.IMAP4_SSL used string concatenation with += in a loop. This lead to exceptionally poor performance retreiving large email messages. Changed both read() and readline() in IMAP4_SSL to aggregate string fragments in a list, then join the elements of the list before returning them. This replaces an O(n^2) algorithm with an O(n) algorithm, for a significant speed increase when retreiving large email messages. ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-11 23:05 Message: Logged In: YES user_id=212920 cool idea, Carl! This is code to remember! Thanks for submitting that! ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2004-05-20 03:17 Message: Logged In: YES user_id=196212 changes checked in. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2004-05-20 02:50 Message: Logged In: YES user_id=196212 Thanks for your changes - will check them in! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=956394&group_id=5470 From noreply at sourceforge.net Mon Jul 12 10:49:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 12 10:49:36 2004 Subject: [Patches] [ python-Patches-846659 ] fix for bug #812325 (tarfile violates bufsize) Message-ID: Patches item #846659, was opened at 2003-11-21 16:53 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #812325 (tarfile violates bufsize) Initial Comment: The attached patch fixes an error in the code for GNU longname/longlink creation. An additional GNU header block is added to the tar file but not summed up to the internal counter (self.offset). On close() the zeropadding is miscalculated which leads to blocksize violation at the end of the archive. I had a conversation with Johan Fredrik ?hman (johanfo) who reported bug #812325 and he told me that my patch solved his problems. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-12 10:49 Message: Logged In: YES user_id=642936 Are there any chances to have this patch (and probably the other pending tarfile patches) applied for the next release? ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2004-02-25 20:12 Message: Logged In: YES user_id=642936 This is now the complete final patchset: - fixes bug #812325. - fixes the second bug in _create_gnulong() I discovered. - adds a testcase for GNUlong extensions. - reverses a patch by A.M. Kuchling which addresses bug #812325 but which is unnecessary. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-22 05:35 Message: Logged In: YES user_id=33168 More tests are always good. :-) I'll try to take a look at this later, or if someone else checks in that's fine too. Also, if I don't get to this, feel free to add the tests to this patch. Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2003-12-16 15:18 Message: Logged In: YES user_id=642936 I must admit, that longnames/longlinks haven't been covered at all by the test suite until now. Shame on me :-( So I'm working on some general testcases right now. While writing the tests, I discovered yet another bug in the longname creation code that must be fixed. Shame on me again :-(( If you agree, Neal, I will submit a second patch that eliminates this new bug and includes a complete set of test cases for both bugs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 16:14 Message: Logged In: YES user_id=33168 Lars, could you add a test case for this as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 From noreply at sourceforge.net Mon Jul 12 11:31:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 12 11:31:47 2004 Subject: [Patches] [ python-Patches-921318 ] Patch for Vinay Sajip's Python-logging package Message-ID: Patches item #921318, was opened at 2004-03-22 19:58 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=921318&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark E. Davidson (medavidson) Assigned to: Vinay Sajip (vsajip) Summary: Patch for Vinay Sajip's Python-logging package Initial Comment: This is a patch for Vinay Sajip's Python-logging package. It adds the support for time-based log rollovers. Specifically, it adds a new handler called TimedRotatingFIleHandler. TimedRotatingFileHandler works just like the existing RotatingFileHandler, except that instead of rolling over when the log file hits a certain size, it rolls over when a time-interval has occurred. You can have the log files rollover ever seconds, minutes, hours, days. You can have log files rollover at midnight. Log files can also roll over on a day of the week. The name of the log file is customized to fit the interval specified. In other words, it's suffix is changed to match the interval you asked for. If you asked for it to roll over every hour, then the log file has a suffix with the year, month, day and hour, but if you roll over on a certain minute, then the suffix also has the minute. I had an extended correspondence with Vinay about this code as I was writing it, so he knows it's coming. It's been mostly tested, but not every variation has been exercised. The rollovers at seconds, minutes, hours have been exercised, as well as the midnight rollover, but the not the day of week. Additionally, the backupCount variation of the TimedRotatingFileHandler is somewhat simplistic and not well tested. This patch only affects handlers.py. It does NOT patch the graphical TkInter-based log configuration utility, as I ran out of time to work on this and Vinay said he might change the class layout. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-07-12 09:31 Message: Logged In: YES user_id=308438 Patch applied in CVS. ---------------------------------------------------------------------- Comment By: Mark E. Davidson (medavidson) Date: 2004-03-25 19:14 Message: Logged In: YES user_id=877141 jimjjewitt is correct. I will try to fix these three issues and upload a new patch in the next day or so. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-25 16:07 Message: Logged In: YES user_id=764593 (1) I think the H in the suffixes need to be capitalized. >>> time.strftime("%Y-%m-%d_%h-%M-%S", tt) '2004-03-25_-53-07' >>> time.strftime("%Y-%m-%d_%H-%M-%S", tt) '2004-03-25_10-53-07' (2) When globbing for old logfiles to delete, please make it more specfic. For instance, all suffixes (for the next century) start with "20", so you could use s = glob.glob(self.basFilename + ".20*") This will make it a bit less dangerous for someone to copy a file as basename.save when they want to save the info for debugging later. (3) The midnight and weekly versions should recalculate the rolloverAt instead of adding interval. This will keep them from getting out of synch if there is a maintenance window or daylight savings time change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=921318&group_id=5470 From noreply at sourceforge.net Mon Jul 12 14:10:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 12 14:10:50 2004 Subject: [Patches] [ python-Patches-983164 ] MSVC6/7 issues with bdist_wininst and --target-version Message-ID: Patches item #983164, was opened at 2004-07-01 05:26 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: MSVC6/7 issues with bdist_wininst and --target-version Initial Comment: bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-12 14:10 Message: Logged In: YES user_id=11105 Hm, it's not as cool as I thought - you only get the new distutils features from the bdist_wininst command, not from other commands. For example, the new 'package_data' option doesn't work for target-version 2.3, since the build tree is still created with the 2.3 distutils. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-10 15:47 Message: Logged In: YES user_id=14198 The point is to use a *new* distutils with an old Python version - ie, I want to use the latest distutils features to build a Python 1.5.2 distribution. OK, maybe not 1.5.2 anymore ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-10 13:36 Message: Logged In: YES user_id=21627 I'd like to mention that --target-version isn't really needed, IMO: it is relatively easy to just use the old Python executable to run setup.py, and it will automatically use the old distutils. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-06 21:23 Message: Logged In: YES user_id=11105 Ah, now I understand. I didn't even know that it was possible to use --target-version and --skip-build to build installers for other Python versions, but this is definitely cool. I checked in your patch to make sure it gets into 2.4a1. Your idea to specify an executable makes sense, but imo only when 2.4 is an old version, isn't it? Feel free to provide an additional patch for that, but I think one should still be able to use '2.3' as argument for the --target-version switch. BTW: The short variant of the --target-version switch (-v) conflicts with the --verbose option and doesn't work, so I'm taking this out as well. Checked in as bdist_wininst.py rev 1.49. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-07-02 01:19 Message: Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:59 Message: Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-01 21:39 Message: Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983164&group_id=5470 From noreply at sourceforge.net Mon Jul 12 15:17:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 12 15:17:21 2004 Subject: [Patches] [ python-Patches-988698 ] compiler.transformer fix for (a, b) = 1, 2 Message-ID: Patches item #988698, was opened at 2004-07-11 00:44 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John Ehresman (jpe) >Assigned to: Michael Hudson (mwh) Summary: compiler.transformer fix for (a, b) = 1, 2 Initial Comment: This fixes bug 988613 in the compiler.transformer. A mimimal unittest file will also be attached. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-12 14:17 Message: Logged In: YES user_id=6656 Life's too short to wait for Jeremy :-) Applied as Lib/compiler/transformer.py revision 1.40 Lib/test/test_transformer.py revision 1.1 Thanks! ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-11 01:02 Message: Logged In: YES user_id=2772 This looks good to me. It's the same change as in Python/compile.c:com_assign_sequence() from version 2.302 http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/compile.c?r1=2.301&r2=2.302 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988698&group_id=5470 From fernribeiro52004xz at mailcity.com Mon Jul 12 15:49:33 2004 From: fernribeiro52004xz at mailcity.com (Fernando Ribeiro) Date: Mon Jul 12 15:49:15 2004 Subject: [Patches] Mala Direta por e-mail - Listas atualizadas: http://www.divulgamail.vze.com Message-ID: <20040712134914.3A19F1E4015@bag.python.org> Emails super atualizados para mala direta, listas de e-mails para divulga??o, email marketing, programas para envio e captura de e-mails. Cadastros segmentados por estados e atividades http://www.gueb.de/divulgamail Emails segmentados e genericos para marketing direto (mala direta por e-mail),valida??o de listas de emails,dicas,bulk mail,e-list,lista eletr?nica,cadastros de home pages em sites de buscas, publicidade, propaganda, marketing, bulk mail http://www.gueb.de/divulgamail From noreply at sourceforge.net Mon Jul 12 15:56:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 12 15:57:05 2004 Subject: [Patches] [ python-Patches-986010 ] add missing doc for datetime C API Message-ID: Patches item #986010, was opened at 2004-07-06 08:28 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 Category: Documentation Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add missing doc for datetime C API Initial Comment: Attached is the missing documentation for the accessor macros. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-07-12 07:56 Message: Logged In: YES user_id=619560 You're quite welcome. The structure you added is definiltely an improvement. I did notice one issue and that is the fact that the word "be" is missing from several of the section comments. Specifically, the sentences like "The argument must __BE__ an instance of...." Otherwise, everything looks great. Thanks for taking the time to work with me on this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-11 13:28 Message: Logged In: YES user_id=31435 Thanks again, Anthony. I took the opportunity to rework the docs a bit more, to add some structure to the now-large pile of datetime macros. Doc/api/concrete.tex; new revision: 1.46 Misc/NEWS; new revision: 1.1038 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 From noreply at sourceforge.net Mon Jul 12 22:16:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 12 22:16:34 2004 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 23: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=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From noreply at sourceforge.net Tue Jul 13 10:04:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 13 10:04:30 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Tue Jul 13 10:10:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 13 10:10:11 2004 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-14 23:57 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: sha256 module Initial Comment: This module is a copy of shamodule.c, with the SHA-1 compression function replaced with the SHA-256 compression function (copied from the LibTomCrypt public-domain crypto library). SHA-256 is similar to SHA-1: it's a US Federal Standard hash algorithm (FIPS 180-2). The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). There's other flavors of SHA, but they're not as useful: SHA-384 and SHA-512 are defined on 64-bit values, so are slow on 32-bit architectures. SHA-224 is just silly (it saves 32 bits over SHA-256; that's its sole rationale). ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:10 Message: Logged In: YES user_id=973611 2nd version of documentation for sha256 and sha512 ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-02 01:00 Message: Logged In: YES user_id=973611 Uploading a new sha256 module with a sha224 function, and a sha512 module with a sha384 function. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-06-30 23:48 Message: Logged In: YES user_id=973611 I'm uploading an attempt at documentation for this module. I had trouble installing the tex tools so I'm not sure if it's correct, but it should be easy to fix if not. I'll try to straighten myself out with the tools so I can make sure. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 07:23 Message: Logged In: YES user_id=11375 I can't rule on whether the module should be added or not, so I'll bring it up on python-dev. Feel free to join the resulting thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From noreply at sourceforge.net Tue Jul 13 21:21:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 13 21:21:59 2004 Subject: [Patches] [ python-Patches-946207 ] Non-blocking Socket Server Message-ID: Patches item #946207, was opened at 2004-05-02 02:45 Message generated for change (Comment added) made by mmangino You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Assigned to: Nobody/Anonymous (nobody) Summary: Non-blocking Socket Server Initial Comment: Changed the included Python 2.3.3 SocketServer.py to be non-blocking. I have made a web-server on BaseHTTPServer, but the server could get shot down externally by sending malformed request. Making it very Easy to Perform a Denial of Service. The problem also exists in "Module Docs" web-server To experience problem run Module Docs, and verify that web-server is working telnet to webserver (telnet 127.0.0.1 7464#) type "GET /\r" access any web-page on web-server and notice how it is hung. Replace existing SocketServer.py with included SocketServer.py and re-test noticing that the problem is gone. ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 19:21 Message: Logged In: YES user_id=74879 Can you post a diff for this to make it easier to understand what has changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 From noreply at sourceforge.net Tue Jul 13 21:46:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 13 21:46:43 2004 Subject: [Patches] [ python-Patches-946207 ] Non-blocking Socket Server Message-ID: Patches item #946207, was opened at 2004-05-02 02:45 Message generated for change (Comment added) made by mmangino You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jesper ?JJ? Jurcenoks (jesperjurcenoks) Assigned to: Nobody/Anonymous (nobody) Summary: Non-blocking Socket Server Initial Comment: Changed the included Python 2.3.3 SocketServer.py to be non-blocking. I have made a web-server on BaseHTTPServer, but the server could get shot down externally by sending malformed request. Making it very Easy to Perform a Denial of Service. The problem also exists in "Module Docs" web-server To experience problem run Module Docs, and verify that web-server is working telnet to webserver (telnet 127.0.0.1 7464#) type "GET /\r" access any web-page on web-server and notice how it is hung. Replace existing SocketServer.py with included SocketServer.py and re-test noticing that the problem is gone. ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 19:46 Message: Logged In: YES user_id=74879 Actually, forget the previous request. The better change would be for you to create a ThreadedHTTPServer that inherits from SocketServer.ThreadingTCPServer, i.e. you could use class ThreadingHTTPServer(SocketServer.ThreadingTCPServer): allow_reuse_address = 1 # Seems to make sense in testing environment def server_bind(self): """Override server_bind to store the server name.""" SocketServer.TCPServer.server_bind(self) host, port = self.socket.getsockname()[:2] self.server_name = socket.getfqdn(host) self.server_port = port And then start the server with httpd = ThreadingHTTPServer(server_address,handler) ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-13 19:21 Message: Logged In: YES user_id=74879 Can you post a diff for this to make it easier to understand what has changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946207&group_id=5470 From noreply at sourceforge.net Wed Jul 14 09:04:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 09:04:37 2004 Subject: [Patches] [ python-Patches-935454 ] sha256 module Message-ID: Patches item #935454, was opened at 2004-04-14 23:57 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: sha256 module Initial Comment: This module is a copy of shamodule.c, with the SHA-1 compression function replaced with the SHA-256 compression function (copied from the LibTomCrypt public-domain crypto library). SHA-256 is similar to SHA-1: it's a US Federal Standard hash algorithm (FIPS 180-2). The difference is that it produces a 256 bit hash value, instead of a 160 bit hash value. SHA-256 thus has 128 bits of resistance against birthday attacks, which makes it secure in certain protocols where SHA-1 is questionable (e.g. digital signatures; or RNGs or Key-Derivation Functions where you want to produce keys for 256-bit ciphers). There's other flavors of SHA, but they're not as useful: SHA-384 and SHA-512 are defined on 64-bit values, so are slow on 32-bit architectures. SHA-224 is just silly (it saves 32 bits over SHA-256; that's its sole rationale). ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-07-14 00:04 Message: Logged In: YES user_id=973611 New set of files - full source, patches, and docs for all new SHA versions. Cleans things up a bit: - sha256.c, sha512.c - sha224.py, sha384.py (wrappers) - test_sha*.py - libsha*.tex ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:10 Message: Logged In: YES user_id=973611 2nd version of documentation for sha256 and sha512 ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-02 01:00 Message: Logged In: YES user_id=973611 Uploading a new sha256 module with a sha224 function, and a sha512 module with a sha384 function. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-06-30 23:48 Message: Logged In: YES user_id=973611 I'm uploading an attempt at documentation for this module. I had trouble installing the tex tools so I'm not sure if it's correct, but it should be easy to fix if not. I'll try to straighten myself out with the tools so I can make sure. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-29 07:23 Message: Logged In: YES user_id=11375 I can't rule on whether the module should be added or not, so I'll bring it up on python-dev. Feel free to join the resulting thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=935454&group_id=5470 From noreply at sourceforge.net Wed Jul 14 16:12:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 16:12:26 2004 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 15:22 Message generated for change (Comment added) made by mmangino You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 14:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Wed Jul 14 17:54:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 17:54:53 2004 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 17:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-14 17:54 Message: Logged In: YES user_id=11105 I'm curious: Why did you replace RegEnumKey with RegEnumKeyEx? Are there any advantages of the latter? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 16:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Wed Jul 14 18:12:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 18:13:02 2004 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 15:22 Message generated for change (Comment added) made by garth42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- >Comment By: Garth Bushell (garth42) Date: 2004-07-14 16:12 Message: Logged In: YES user_id=45280 mmangino: Yes you're correct it should be 256 in both cases. Doh! I'll attach a new patch in a while. but It's easy to mmodify the patch and up the linit to 256 theller: The advantage of the latter is it returns the Length of the string returned so we can pass it straight back to the string creation funtion in python without a strlen. also the SDK says this.... Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should use the RegEnumKeyEx function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-14 15:54 Message: Logged In: YES user_id=11105 I'm curious: Why did you replace RegEnumKey with RegEnumKeyEx? Are there any advantages of the latter? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 14:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Wed Jul 14 21:11:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 21:11:19 2004 Subject: [Patches] [ python-Patches-854853 ] shutil.copyfile destroys hard links (Bug [ 851123 ]) Message-ID: Patches item #854853, was opened at 2003-12-05 11:33 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfile destroys hard links (Bug [ 851123 ]) Initial Comment: shutil.copyfile(src,dst) will destroy src if dst is a hard or symbolic link to src. (This is bug [851123].) There was a version of patch [ 604600 ] For Bug [ 490168 ] which sought to address this problem but it wasn't implemented properly. My patch checks for the existence of os.path.samefile(), (which on posix systems follows symlinks) and uses that as a guard if available. It catches the exception raised by samefile() if dst does not exist. (It also catches the exception raised if src does not exist, but this doesn't matter since that condition will cause a new exception in the next part of the code.) I have included test code, which tests for the bug only if os.symlink exists. If there is a platform with symlink but not samefile, the test will fail; I think that would indicate more fixing of shutil.py is required. I avoided using tempfile.mktemp to a degree since that function is now deprecated. I made a judgement call that calling mktemp with a private temp dir (from mkdtemp) is safe. Perhaps in a private temp dir we can just use a hard-coded filename, if mktemp is really despised. Since this is just a bugfix I included no doc updates. ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2004-07-14 15:11 Message: Logged In: YES user_id=11365 I've revised the patch to make the test code more consistent with what was already present. I think this should be accepted or rejected before python2.4 ships, as it is a good complement to Bug #919012. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470 From noreply at sourceforge.net Wed Jul 14 21:28:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 21:28:26 2004 Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust SCRIPT tag parsing Message-ID: Patches item #670664, was opened at 2003-01-19 09:07 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: j paulson (fantoozler) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser.py - more robust SCRIPT tag parsing Initial Comment: http://www.ebay.com contains a script element of the form <SCRIPT> ... vbscript += "</SCR"+"IPT> \n"; ... </SCRIPT> which is not enclosed in "<!-- ... -->" comments. The parser choked on that line, indicating it was a mal-formed end tag. The changes are: interesting_cdata is now a dict mapping start tag to an re matching the end tag, a "<--" or \Z HTMLParser.set_cdata_mode takes an extra argument, the start tag ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-14 15:28 Message: Logged In: YES user_id=3066 Removed older version of the patch. ---------------------------------------------------------------------- Comment By: j paulson (fantoozler) Date: 2003-01-28 17:35 Message: Logged In: YES user_id=690612 You will get a sequence of: handle_starttag("script") handle_comment("some-javascript-code") handle_endtag("script") whereas before the sequence was: handle_starttag("script") handle_data("<!-- ... some-javascript-code ... //-->") handle_endtag("script") ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 17:24 Message: Logged In: YES user_id=3066 >From python-dev: John Paulson wrote: > [...] A side-effect of this is that > any "<!--" .. "-->" within a script/style will > be parsed as a comment. If that behavior is > incorrect, the regex can be modified. Jerry Williams wrote: Does this mean that the following won't work: <SCRIPT language="JavaScript"> <!-- // some-javascript-code // --> </SCRIPT> That could be a problem, since this is commonly used to support browsers that don't understand <SCRIPT>. See: http://mail.python.org/pipermail/python-dev/2003-January/032482.html ---------------------------------------------------------------------- Comment By: j paulson (fantoozler) Date: 2003-01-24 22:58 Message: Logged In: YES user_id=690612 Found regression test, used it, found error, fixed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470 From noreply at sourceforge.net Wed Jul 14 22:44:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 14 22:44:07 2004 Subject: [Patches] [ python-Patches-989712 ] Support using Tk without a mainloop Message-ID: Patches item #989712, was opened at 2004-07-12 15:16 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) >Assigned to: Kurt B. Kaiser (kbk) Summary: Support using Tk without a mainloop Initial Comment: In the regular python shell, you can open Tk windows, and they will operate even though you didn't call Tkinter.mainloop(). This is useful, for example, when you manipulate matplotlib graphs from within the python shell. This is done by a hook, installed when a tkapp object is being initialized, which handles Tk events while the shell is waiting for user input. I imitated this behaviour in IDLE: When the subprocess is idle, it checks whether Tkinter._default_root is set (this happens when the Tkinter.Tk class, which makes a tkapp object, is initialized, unless Tkinter._use_default_root is False), and if so, handles Tk events. For me it works very well. Have a good day, Noam Raphael ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-07-14 15:44 Message: Logged In: YES user_id=149084 Can you give me some more information on the hook in the Python interpreter? Where is it in the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=989712&group_id=5470 From e.lamboz at telestet.gr Wed Jul 14 22:58:40 2004 From: e.lamboz at telestet.gr (Elbert Lamb) Date: Wed Jul 14 22:58:22 2004 Subject: [Patches] $49757 Message-ID: Hi, I sent you an email a few days ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link: http://www.web-lender.com/p3/li.php?weo=71 Best Regards, Elbert ---- system information ---- greater interoperability Each Tags relevant part forethought end procedure form generic subject preferred a similar call issues read by produced interaction interoperate usage implement From noreply at sourceforge.net Thu Jul 15 08:30:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 15 08:30:22 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-12 00:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 08:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 20:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 20:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 08:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 16:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 06:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 15:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Thu Jul 15 20:30:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 15 20:31:05 2004 Subject: [Patches] [ python-Patches-947352 ] AF_PACKET Hardware address support in socket module Message-ID: Patches item #947352, was opened at 2004-05-03 19:36 Message generated for change (Comment added) made by thedeuce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Andryuk (thedeuce) Assigned to: A.M. Kuchling (akuchling) Summary: AF_PACKET Hardware address support in socket module Initial Comment: The current implementation of AF_PACKET only uses the device name and protocol options even when a 5-tuple of Device, Protocol, Packet Type, Hardware Type, and Hardware Address are supplied. I needed socket.sendto() to support sending to a Hardware Address, so this patch supports such functionality. The length check on the hardware address is hard coded to 8 since that is the value used in the sockaddr_ll struct. I'm not that familiar with the Python internals, so s->errorhandler() may not be the best call to make for an invalid hardware address length. ---------------------------------------------------------------------- >Comment By: Jason Andryuk (thedeuce) Date: 2004-07-15 14:30 Message: Logged In: YES user_id=1034404 Yeah, ValueError looks good, and it sends out packets to the desired address just fine. Thank You ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 19:40 Message: Logged In: YES user_id=11375 Checked in to CVS HEAD; thanks for the patch! I think s_errorhandler is only when you're trying to report the error from a system call; I changed to raise a ValueError if the hardware address is too long. Please give the CVS version a try and let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 From noreply at sourceforge.net Thu Jul 15 21:08:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 15 21:08:11 2004 Subject: [Patches] [ python-Patches-947352 ] AF_PACKET Hardware address support in socket module Message-ID: Patches item #947352, was opened at 2004-05-03 19:36 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 Category: Modules >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Andryuk (thedeuce) Assigned to: A.M. Kuchling (akuchling) Summary: AF_PACKET Hardware address support in socket module Initial Comment: The current implementation of AF_PACKET only uses the device name and protocol options even when a 5-tuple of Device, Protocol, Packet Type, Hardware Type, and Hardware Address are supplied. I needed socket.sendto() to support sending to a Hardware Address, so this patch supports such functionality. The length check on the hardware address is hard coded to 8 since that is the value used in the sockaddr_ll struct. I'm not that familiar with the Python internals, so s->errorhandler() may not be the best call to make for an invalid hardware address length. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-15 15:08 Message: Logged In: YES user_id=11375 Thanks for the confirmation; marking this as closed. ---------------------------------------------------------------------- Comment By: Jason Andryuk (thedeuce) Date: 2004-07-15 14:30 Message: Logged In: YES user_id=1034404 Yeah, ValueError looks good, and it sends out packets to the desired address just fine. Thank You ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-10 19:40 Message: Logged In: YES user_id=11375 Checked in to CVS HEAD; thanks for the patch! I think s_errorhandler is only when you're trying to report the error from a system call; I changed to raise a ValueError if the hardware address is too long. Please give the CVS version a try and let me know if it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947352&group_id=5470 From noreply at sourceforge.net Fri Jul 16 02:47:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 16 02:47:37 2004 Subject: [Patches] [ python-Patches-992055 ] socketmodule on OpenBSD/sparc64 (64bit machine) Message-ID: Patches item #992055, was opened at 2004-07-16 02: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=992055&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aleksander Piotrowski (pelotas) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule on OpenBSD/sparc64 (64bit machine) Initial Comment: perky@users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory sc8-pr-cvs1:/tmp/cvs-serv3617 > > Modified Files: > socketmodule.c > Log Message: > Fix erroneus argument parsing of socket.htons() on 64bit big endian > machines. This is cool but not enough. There is another place where 64 bit machines fail. Here is diff. With it my OpenBSD/sparc64 passes all socket tests (test_socket). Of course OpenBSD/i386 is still working OK. [diff attached] Hye-Shik Chang had already replied. Here is what he said: [...] But return value type of inet_addr(3) and its size has complex issues because it is used for not only OpenBSD but also BeOS, IRIX, old BSDs, Windows and etc. that I don't have an access. I think you'd better to submit it to SF tracker [...] So I'm submiting it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992055&group_id=5470 From noreply at sourceforge.net Fri Jul 16 02:50:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 16 02:50:31 2004 Subject: [Patches] [ python-Patches-992055 ] socketmodule on OpenBSD/sparc64 (64bit machine) Message-ID: Patches item #992055, was opened at 2004-07-16 02:47 Message generated for change (Comment added) made by pelotas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992055&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aleksander Piotrowski (pelotas) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule on OpenBSD/sparc64 (64bit machine) Initial Comment: perky@users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory sc8-pr-cvs1:/tmp/cvs-serv3617 > > Modified Files: > socketmodule.c > Log Message: > Fix erroneus argument parsing of socket.htons() on 64bit big endian > machines. This is cool but not enough. There is another place where 64 bit machines fail. Here is diff. With it my OpenBSD/sparc64 passes all socket tests (test_socket). Of course OpenBSD/i386 is still working OK. [diff attached] Hye-Shik Chang had already replied. Here is what he said: [...] But return value type of inet_addr(3) and its size has complex issues because it is used for not only OpenBSD but also BeOS, IRIX, old BSDs, Windows and etc. that I don't have an access. I think you'd better to submit it to SF tracker [...] So I'm submiting it. ---------------------------------------------------------------------- >Comment By: Aleksander Piotrowski (pelotas) Date: 2004-07-16 02:50 Message: Logged In: YES user_id=883833 Yuck. This looks ugly. Close this patch and I'll resubmit it. Sorry :/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992055&group_id=5470 From noreply at sourceforge.net Fri Jul 16 11:13:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 16 11:17:29 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 16 11:16:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 16 11:20:06 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From belts at i-love-mancity.com Sat Jul 17 03:04:56 2004 From: belts at i-love-mancity.com (Didn K. Lisp) Date: Sat Jul 17 02:36:26 2004 Subject: [Patches] Exceptional deals for medication on our site. Message-ID: <101001c46b9a$b04200f9$59745452@i-love-mancity.com> Up and doing! You never will be the person you can be if pressure, tension and discipline are taken out of your life. Building a better you is the first step to building a better America. http://sweatshop.jejufl.com/3/ Thought are but dreams till their effects are tried. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040716/6731fe84/attachment.htm From noreply at sourceforge.net Sat Jul 17 03:44:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 03:44:32 2004 Subject: [Patches] [ python-Patches-986010 ] add missing doc for datetime C API Message-ID: Patches item #986010, was opened at 2004-07-06 10:28 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 Category: Documentation Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: add missing doc for datetime C API Initial Comment: Attached is the missing documentation for the accessor macros. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-16 21:44 Message: Logged In: YES user_id=31435 Oops! The missing "be" was, of course, repeated copy+paste+edit damage. Thanks for noticing. Repaired in Doc/api/concrete.tex, revision 1.47 ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-07-12 09:56 Message: Logged In: YES user_id=619560 You're quite welcome. The structure you added is definiltely an improvement. I did notice one issue and that is the fact that the word "be" is missing from several of the section comments. Specifically, the sentences like "The argument must __BE__ an instance of...." Otherwise, everything looks great. Thanks for taking the time to work with me on this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-11 15:28 Message: Logged In: YES user_id=31435 Thanks again, Anthony. I took the opportunity to rework the docs a bit more, to add some structure to the now-large pile of datetime macros. Doc/api/concrete.tex; new revision: 1.46 Misc/NEWS; new revision: 1.1038 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986010&group_id=5470 From noreply at sourceforge.net Sat Jul 17 05:06:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 05:06:43 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 04:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-16 23:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 04:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Sat Jul 17 08:04:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 08:04:51 2004 Subject: [Patches] [ python-Patches-943953 ] Add maketrans to string object Message-ID: Patches item #943953, was opened at 2004-04-29 04:43 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943953&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gyro Funch (siva1311) Assigned to: Nobody/Anonymous (nobody) Summary: Add maketrans to string object Initial Comment: Added maketrans method to the string object. This functionality is currently only in the string module. string module -> str object string.maketrans(from,to) -> from.maketrans(to) Attached is the diff for stringobject.c and string_test.py I am not a proficient C coder, but things look okay to me and the tests pass. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-07-17 15:04 Message: Logged In: YES user_id=55188 unicode object have got .decode() method. It seems the originator may feel happy to write his own codec package now. :) ---------------------------------------------------------------------- Comment By: Denis S. Otkidach (ods) Date: 2004-05-15 00:07 Message: Logged In: YES user_id=63454 > About your note about the Unicode .decode() method: > I completely agree. The codec was never designed to > be Unicode vs. the rest of the world. It was designed > as general purpose encoding and decoding system. If so, we need to relax mentioned restriction and allow Codec instance as argument of encode/decode methods. Without this codecs never become general purpose encoding and decoding system. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-14 23:45 Message: Logged In: YES user_id=38388 >>It is easy enough to write a charset based >> codec that fullfills the same need. > > This approach won't work for both str and unicode due to > over-restricted implementation of codecs: > http://groups.google.com/groups?th=a68a7b5a2e1f294 . > Moreover, AFAIK this requires regestering encoding > (making it global), but this is often a bad idea. Indeed. I've always argued for putting codecs into packages for this reason. About your note about the Unicode .decode() method: I completely agree. The codec was never designed to be Unicode vs. the rest of the world. It was designed as general purpose encoding and decoding system. However, a few python-dev'ers seem to have misunderstood this intention and still believe that codecs are only about Unicode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-14 23:40 Message: Logged In: YES user_id=38388 Probably... patches are welcome :-) Writing these codecs is really easy. Just have a look at e.g. rot13.py ... you basically copy the template to a new module say rot14, edit the mapping dictionary, save it and then use the module name in the string .encode() method: 'abc'.encode('rot14') The codec registry will first look in the encodings package for the codec and then continue the search on the PYTHONPATH, so you may have to provide the complete package name if you place the codec into a package, e.g. 'abc'.encode('my.new.app.rot14') That's it. ---------------------------------------------------------------------- Comment By: Denis S. Otkidach (ods) Date: 2004-05-14 23:40 Message: Logged In: YES user_id=63454 > I'm -1 on adding such a method or trying to tweak .translate(): > We should not make use of .translate() more wide-spread > than it already is. Then why it's not deprecated yet? Now translate has many disadvantages: it's difficult ro use for str (need maketrans), the interface of it differ for str and unicode. I suggested to add unified interface and avoid maketrans use. I'm not the first who doesn't like maketrans: http://mail.python.org/pipermail/patches/2000-May/000781.html > It is easy enough to write a charset based > codec that fullfills the same need. This approach won't work for both str and unicode due to over-restricted implementation of codecs: http://groups.google.com/groups?th=a68a7b5a2e1f294 . Moreover, AFAIK this requires regestering encoding (making it global), but this is often a bad idea. ---------------------------------------------------------------------- Comment By: Gyro Funch (siva1311) Date: 2004-05-14 23:30 Message: Logged In: YES user_id=679947 Okay. I wasn't even aware of the encodings package (blush). Should the docs be updated to reflect the fact that users should consider using codecs instead of translate/maketrans? Perhaps an example of how maketrans/translate is subsumed by codecs would be helpful. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-14 23:13 Message: Logged In: YES user_id=38388 I'm -1 on adding such a method or trying to tweak .translate(): We should not make use of .translate() more wide-spread than it already is. It is easy enough to write a charset based codec that fullfills the same need. See the codecs in the encodings package on how to use this codec for purpose very similar to those of .translate(). The advantage of this approach is not only to make the resulting translation easily available to the whole application; it also works for both Unicode and plain strings by virtue of the charset codec. ---------------------------------------------------------------------- Comment By: Denis S. Otkidach (ods) Date: 2004-05-14 23:05 Message: Logged In: YES user_id=63454 No, my suggestion doesn't interfer with current interface, so it can be added without breaking compatibility. Something like the following. For str: if isinstance(table, str): ...old behavior... else: t_from, t_to = table; ... For unicode: if isinstance(tables, dict): ...old behavior... else: t_from, t_to = table; ... ---------------------------------------------------------------------- Comment By: Gyro Funch (siva1311) Date: 2004-05-14 22:51 Message: Logged In: YES user_id=679947 Although I think your suggestion would have merit if this method were new, in the current situation this change would break all code currently using the 'translate' method. I can't imagine that this would be acceptable. My suggested change would be backward compatible and would be consistent with bringing methods out of the string module and into str object methods. Since 'translate' has already been made a str method, why not make 'maketrans' a str method too? ---------------------------------------------------------------------- Comment By: Denis S. Otkidach (ods) Date: 2004-05-14 21:59 Message: Logged In: YES user_id=63454 I think maketrans is a low-level function and should be hidden from user. Traditional tr interface is much more tentative and it can be the same both for str and unicode: s.translate((from, to) [, delete]). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943953&group_id=5470 From noreply at sourceforge.net Sat Jul 17 09:13:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 09:14:27 2004 Subject: [Patches] [ python-Patches-731151 ] pimp.py has old URL for default database Message-ID: Patches item #731151, was opened at 2003-05-02 13:53 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731151&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Nobody/Anonymous (nobody) Summary: pimp.py has old URL for default database Initial Comment: The default database in pimp.py points to an address on www.cwi.nl, which has been superceded by one on homepages.cwi.nl. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-07-17 16:13 Message: Logged In: YES user_id=55188 Fixed already in pimp.py 1.29. (Found by Seo Sanghyeon at KLDP CodeFest) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731151&group_id=5470 From noreply at sourceforge.net Sat Jul 17 09:45:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 09:45:43 2004 Subject: [Patches] [ python-Patches-992750 ] zipfile and big zipped file Message-ID: Patches item #992750, was opened at 2004-07-17 09: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=992750&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keyphrene (keyphrene) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile and big zipped file Initial Comment: read method decompress the zipped files, but this method returns bytes, more the file is big, more the bytes array is big. readFile method allows to send the bytes in a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470 From noreply at sourceforge.net Sat Jul 17 10:12:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 10:12:48 2004 Subject: [Patches] [ python-Patches-992055 ] socketmodule on OpenBSD/sparc64 (64bit machine) Message-ID: Patches item #992055, was opened at 2004-07-16 02:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992055&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Aleksander Piotrowski (pelotas) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule on OpenBSD/sparc64 (64bit machine) Initial Comment: perky@users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory sc8-pr-cvs1:/tmp/cvs-serv3617 > > Modified Files: > socketmodule.c > Log Message: > Fix erroneus argument parsing of socket.htons() on 64bit big endian > machines. This is cool but not enough. There is another place where 64 bit machines fail. Here is diff. With it my OpenBSD/sparc64 passes all socket tests (test_socket). Of course OpenBSD/i386 is still working OK. [diff attached] Hye-Shik Chang had already replied. Here is what he said: [...] But return value type of inet_addr(3) and its size has complex issues because it is used for not only OpenBSD but also BeOS, IRIX, old BSDs, Windows and etc. that I don't have an access. I think you'd better to submit it to SF tracker [...] So I'm submiting it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-17 10:12 Message: Logged In: YES user_id=21627 Ok, closed. ---------------------------------------------------------------------- Comment By: Aleksander Piotrowski (pelotas) Date: 2004-07-16 02:50 Message: Logged In: YES user_id=883833 Yuck. This looks ugly. Close this patch and I'll resubmit it. Sorry :/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992055&group_id=5470 From noreply at sourceforge.net Sat Jul 17 10:13:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 10:13:51 2004 Subject: [Patches] [ python-Patches-984654 ] socket module does not support AF_NETLINK Message-ID: Patches item #984654, was opened at 2004-07-03 18:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket module does not support AF_NETLINK Initial Comment: [forwarded from http://bugs.debian.org/257444] The socket module is missing the AF_NETLINK constant and the associated support, as well as a whole bunch of others. The list of missing address families seems to be: #define AF_ATMPVC 8 /* ATM PVCs */ #define AF_DECnet 12 /* Reserved for DECnet project */ #define AF_NETBEUI 13 /* Reserved for 802.2LLC project*/ #define AF_SECURITY 14 /* Security callback pseudo AF */ #define AF_KEY 15 /* PF_KEY key management API */ #define AF_NETLINK 16 #define AF_ROUTE AF_NETLINK /* Alias to emulate 4.4BSD */ #define AF_ASH 18 /* Ash */ #define AF_ECONET 19 /* Acorn Econet */ #define AF_ATMSVC 20 /* ATM SVCs */ #define AF_SNA 22 /* Linux SNA Project (nutters!) */ #define AF_IRDA 23 /* IRDA sockets */ #define AF_PPPOX 24 /* PPPoX sockets */ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC */ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-17 10:13 Message: Logged In: YES user_id=21627 I think the request is about adding the constants if the system offers them; I have no problems with that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 16:45 Message: Logged In: YES user_id=11375 This is really a feature request. It would be easy to add the various AF_* constants to the module, but truly supporting all these new families requires appropriate changes to the makesockaddr(), getsockaddrarg(), and getsockaddrlen() functions in Modules/socketmodule.c. I don't know what the address strings/objects for the various families look like, and have no idea where to find such information. If AF_NETLINK is important, we can certainly try to implement that one family. Something obscure like AF_SNA is unlikely to ever be supported in the absence of a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 From noreply at sourceforge.net Sat Jul 17 12:17:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 12:17:52 2004 Subject: [Patches] [ python-Patches-908631 ] WinSock 2 support on Win32 w/ MSVC++ 6 (fix #860134) Message-ID: Patches item #908631, was opened at 2004-03-02 15:16 Message generated for change (Comment added) made by jeffconnelly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=908631&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: WinSock 2 support on Win32 w/ MSVC++ 6 (fix #860134) Initial Comment: WinSock 2 isn't supported on 2.3. The capability is there, but the Microsoft C++ version is incorrectly specified to the preprocessor, VC++ 6 (the version used to build the official Python Win32 executable) misses the #if's and links to wsock32.lib, instead. This results in the programmer only being able to use WinSock 1, instead of WinSock 2's useful functions. On modern Win32's, WinSock 2 is prevalent, so the switch shouldn't cause too much trouble, as well as providing additional functionality. The problem appears to be line 16 of socketmodule.h, which includes WinSock 2 #if _MSC_VER >= 1300 and WinSock 1 otherwise. (IP_HDRINCL is a part of WinSock 2.) Apply this patch to use WinSock 2 on MS VC++ 6 (1200), which is what the Python Win32 builds are compiled with. (1300 is .Net? maybe?) pyconfig.h also needs to be patched. Also, the _socket moduleneeds to link with ws2_32.lib instead of wsock32.lib. (Project -> Settings -> highlight _socket -> Win32 release -> Link tab -> in "Object/library modules" change wsock32.lib to ws2_32.lib). With these changes, IP_HDRINCL exists in socket: C:\>python Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.IP_HDRINCL 2 >>> And it works as it should, as do other obscure WinSock 2 functions. ---------------------------------------------------------------------- >Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-07-17 03:17 Message: Logged In: YES user_id=31953 Can this change be merged into the current source tree? I need WinSock 2 for my application and distributing a patched version of Python isn't very elegant. ---------------------------------------------------------------------- Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-03-02 15:20 Message: Logged In: YES user_id=31953 P.S.: The original bug report is here: https://sourceforge.net/tracker/index.php? func=detail&aid=860134&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-03-02 15:18 Message: Logged In: YES user_id=31953 P.S.: The original bug report is here: https://sourceforge.net/tracker/index.php? func=detail&aid=860134&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=908631&group_id=5470 From noreply at sourceforge.net Sat Jul 17 16:05:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 16:05:21 2004 Subject: [Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE undefined Message-ID: Patches item #968728, was opened at 2004-06-08 17:48 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Michael Schloh von Bennewitz (michaesc) Assigned to: Nobody/Anonymous (nobody) Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined Initial Comment: In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and Solaris 10 SPARC, this causes a build failure. I'm ashamed to say that I wasn't able to 100% diagnose this problem (I didn't have time). My first guess was that somehow HUGE_VAL was not getting properly defined on Solaris 10 due to its rewritten /usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL depending on a _STDC_C99 and _XOPEN_SOURCE definition). Because I noticed that the identifier HUGE is unconditionally defined on Solaris 10 and seemingly all earlier Solaris releases, I tried using that instead and the build problem disappeared. You can make your own conclusion as to whether my fix is correct, or if there is a better way to solve this problem. There may be a faulty assumption made by configure or in some Makefile of how the compiler is being used, or maybe python depends on a certain GCC release. CC: GCC 3.4.0 CXX: GCC 3.4.0 CFLAGS: -O2 -pipe CXXFLAGS: -O2 -pipe CPPFLAGS: None Make: GNU Make 3.80 LDFLAGS: None mich@dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw checking MACHDEP... freebsd4 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no ... The OpenPKG Python package and patch: http://cvs.openpkg.org/dir?d=openpkg-src/python http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch Lots of luck, and thanks for maintaining Python. Regards, Michael, OpenPKG http://www.openpkg.org/ ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-07-17 23:05 Message: Logged In: YES user_id=55188 This doesn't look like a bug in Python per Tim's comment. (Reviewed by Seo Sanghyeon and me at KLDP CodeFest) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-09 04:02 Message: Logged In: YES user_id=31435 I don't see a reason to call this a Python bug. The C89 and C99 standards both require that math.h supply the HUGE_VAL macro. If the compilation system you're using doesn't do so, it's a bug in that system, and should be fixed there. Python doesn't ask for much, but does require an ANSI C compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470 From noreply at sourceforge.net Sat Jul 17 21:12:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 17 21:12:29 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 15:50 Message generated for change (Comment added) made by asouzis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 12:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 02:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 02:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-14 23:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 11:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 11:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-23 23:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 07:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 21:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 06:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From homer.huggins_rm at unesco.org.br Sat Jul 17 23:44:12 2004 From: homer.huggins_rm at unesco.org.br (homer.huggins_rm@unesco.org.br) Date: Sat Jul 17 23:46:15 2004 Subject: [Patches] $31446 Message-ID: Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://cash-market.info/p3/li.php?weo=71 Best Regards, Jamie Higgs ---- system information ---- architecture distinctions contrast between status times distinctions categories backgrounds reports revised called matching technical usage exchanged no greater works examples standard each needs acceptable From noreply at sourceforge.net Sun Jul 18 01:06:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 18 01:07:01 2004 Subject: [Patches] [ python-Patches-993062 ] cgi.parse_qs: make an empty string give {}, like in 2.3. Message-ID: Patches item #993062, was opened at 2004-07-17 23:06 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=993062&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richie Hindle (richiehindle) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.parse_qs: make an empty string give {}, like in 2.3. Initial Comment: Prior to 2.4, cgi.parse_qs("", keep_blank_values=True) returned {}. It now returns {'': ['']}. This patch restores the old behaviour without breaking the edit that introduced it, namely that parse_qs("pog", keep_blank_values=True) should return {'pog': ['']}. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993062&group_id=5470 From noreply at sourceforge.net Sun Jul 18 03:20:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 18 03:20:41 2004 Subject: [Patches] [ python-Patches-737473 ] traceback module caches sources invalid Message-ID: Patches item #737473, was opened at 2003-05-14 14:44 Message generated for change (Comment added) made by falsetru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: traceback module caches sources invalid Initial Comment: traceback.{extract,print}_tb function doesn't check source code's mtime validity. attached script copies the bug situation. ---------------------------------------------------------------------- Comment By: Jung-Min Lee (falsetru) Date: 2004-07-18 10:20 Message: Logged In: YES user_id=1004332 tested on Linux 2.6.7, attached test_tracebackreload.py passed. btw, test_tracebackreload.py don't remove temporary file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 From noreply at sourceforge.net Sun Jul 18 09:16:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 18 09:16:10 2004 Subject: [Patches] [ python-Patches-993173 ] audioop extension should be enabled on 64-bit archs Message-ID: Patches item #993173, was opened at 2004-07-18 07: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=993173&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: audioop extension should be enabled on 64-bit archs Initial Comment: [ forwarded from http://bugs.debian.org/260051 ] Patch submitter writes: The audioop extension is disabled on 64-bit architectures, but the reasoning used in the justification is flawed; it checks for whether "maxint" is a 64-bit value, which it is, but audioop explicitly uses a 32-bit integer type everywhere. The attached patch re-enables this extension; tested on alpha-linux, works fine. The imageop and rgbimg extensions may also be usable on 64-bit platforms, but I haven't tested them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993173&group_id=5470 From noreply at sourceforge.net Sun Jul 18 10:08:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 18 10:08:40 2004 Subject: [Patches] [ python-Patches-993187 ] Fix docs for string/rstrip Message-ID: Patches item #993187, was opened at 2004-07-18 08: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=993187&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docs for string/rstrip Initial Comment: [forwarded from http://bugs.debian.org/260051] In the file /usr/share/doc/python2.3/html/lib/module-string.html in the passage describing rstrip, it says: 'The chars parameter cannot be passed in 2.2 versions.' It should say: 'The chars parameter cannot be passed in earlier 2.2 versions.' This fixed sentence matches similar sentences in the documentation for lstrip and strip and makes more sense (since 2.2.3 is a 2.2 version itself). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993187&group_id=5470 From noreply at sourceforge.net Sun Jul 18 10:12:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 18 10:12:14 2004 Subject: [Patches] [ python-Patches-993189 ] audioop extension should be enabled on 64-bit archs Message-ID: Patches item #993189, was opened at 2004-07-18 08: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=993189&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: audioop extension should be enabled on 64-bit archs Initial Comment: [ forwarded from http://bugs.debian.org/260051 ] Patch submitter writes: The audioop extension is disabled on 64-bit architectures, but the reasoning used in the justification is flawed; it checks for whether "maxint" is a 64-bit value, which it is, but audioop explicitly uses a 32-bit integer type everywhere. The attached patch re-enables this extension; tested on alpha-linux, works fine. The imageop and rgbimg extensions may also be usable on 64-bit platforms, but I haven't tested them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993189&group_id=5470 From reidrice_bm at liverpool-victoria.co.uk Sun Jul 18 11:44:28 2004 From: reidrice_bm at liverpool-victoria.co.uk (reidrice_bm@liverpool-victoria.co.uk) Date: Sun Jul 18 11:59:36 2004 Subject: [Patches] $17168 Message-ID: Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://cash-market.info/p3/li.php?weo=71 Best Regards, Jamie Higgs ---- system information ---- believes by location substantial dictionary checking substantial source model referred fallback section entities locale-affected Alternate Japanese display localization work Semantics: I-025: inappropriate without culturally From noreply at sourceforge.net Mon Jul 19 03:14:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 03:14:52 2004 Subject: [Patches] [ python-Patches-993189 ] audioop extension should be enabled on 64-bit archs Message-ID: Patches item #993189, was opened at 2004-07-18 04:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993189&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: audioop extension should be enabled on 64-bit archs Initial Comment: [ forwarded from http://bugs.debian.org/260051 ] Patch submitter writes: The audioop extension is disabled on 64-bit architectures, but the reasoning used in the justification is flawed; it checks for whether "maxint" is a 64-bit value, which it is, but audioop explicitly uses a 32-bit integer type everywhere. The attached patch re-enables this extension; tested on alpha-linux, works fine. The imageop and rgbimg extensions may also be usable on 64-bit platforms, but I haven't tested them. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-18 21:14 Message: Logged In: YES user_id=33168 Duplicate of 993173. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993189&group_id=5470 From noreply at sourceforge.net Mon Jul 19 03:24:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 03:24:21 2004 Subject: [Patches] [ python-Patches-993062 ] cgi.parse_qs: make an empty string give {}, like in 2.3. Message-ID: Patches item #993062, was opened at 2004-07-17 19:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993062&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richie Hindle (richiehindle) >Assigned to: Brett Cannon (bcannon) Summary: cgi.parse_qs: make an empty string give {}, like in 2.3. Initial Comment: Prior to 2.4, cgi.parse_qs("", keep_blank_values=True) returned {}. It now returns {'': ['']}. This patch restores the old behaviour without breaking the edit that introduced it, namely that parse_qs("pog", keep_blank_values=True) should return {'pog': ['']}. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-18 21:24 Message: Logged In: YES user_id=33168 Brett, you changed the keep_blank_values, do you agree with this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993062&group_id=5470 From temple_de at tegis.de Mon Jul 19 06:44:59 2004 From: temple_de at tegis.de (temple_de@tegis.de) Date: Mon Jul 19 06:47:41 2004 Subject: [Patches] $31446 Message-ID: <0ab201c46d4b$8411757f$baaf9bd3@startkabel.nl> Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- grammar parsing future updated generic depending MIME radical-stroke preference ID term disclosures location affected patterns patterns procedure Results: request similar-looking Tags subscribe specific scenarios From noreply at sourceforge.net Mon Jul 19 13:00:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 13:00:57 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Mon Jul 19 15:12:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 15:13:11 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) >Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Mon Jul 19 17:52:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 17:53:20 2004 Subject: [Patches] [ python-Patches-737473 ] traceback module caches sources invalid Message-ID: Patches item #737473, was opened at 2003-05-14 06:44 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: traceback module caches sources invalid Initial Comment: traceback.{extract,print}_tb function doesn't check source code's mtime validity. attached script copies the bug situation. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-19 16:52 Message: Logged In: YES user_id=6656 Check it in already! I've been wanting to do something about this for years... One of the things stopping me was wanting to take the time to check whether it's worth bothering with linecache at all in traceback -- but this'll do :-) ---------------------------------------------------------------------- Comment By: Jung-Min Lee (falsetru) Date: 2004-07-18 02:20 Message: Logged In: YES user_id=1004332 tested on Linux 2.6.7, attached test_tracebackreload.py passed. btw, test_tracebackreload.py don't remove temporary file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 From noreply at sourceforge.net Mon Jul 19 18:34:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 18:34:43 2004 Subject: [Patches] [ python-Patches-993187 ] Fix docs for string/rstrip Message-ID: Patches item #993187, was opened at 2004-07-18 10:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993187&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docs for string/rstrip Initial Comment: [forwarded from http://bugs.debian.org/260051] In the file /usr/share/doc/python2.3/html/lib/module-string.html in the passage describing rstrip, it says: 'The chars parameter cannot be passed in 2.2 versions.' It should say: 'The chars parameter cannot be passed in earlier 2.2 versions.' This fixed sentence matches similar sentences in the documentation for lstrip and strip and makes more sense (since 2.2.3 is a 2.2 version itself). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-19 18:34 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libstring.tex 1.52.8.2 and 1.58. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993187&group_id=5470 From noreply at sourceforge.net Mon Jul 19 18:52:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 18:52:13 2004 Subject: [Patches] [ python-Patches-993173 ] audioop extension should be enabled on 64-bit archs Message-ID: Patches item #993173, was opened at 2004-07-18 09:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993173&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: audioop extension should be enabled on 64-bit archs Initial Comment: [ forwarded from http://bugs.debian.org/260051 ] Patch submitter writes: The audioop extension is disabled on 64-bit architectures, but the reasoning used in the justification is flawed; it checks for whether "maxint" is a 64-bit value, which it is, but audioop explicitly uses a 32-bit integer type everywhere. The attached patch re-enables this extension; tested on alpha-linux, works fine. The imageop and rgbimg extensions may also be usable on 64-bit platforms, but I haven't tested them. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-19 18:52 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as setup.py 1.194 Setup.dist 1.46 Notice that the test for MAXINT is not a justification, but the test itself to check for 64-bitness. The claim that the module does not work on 64-bit systems originates from 1.65 of Modules/Setup.in. Unfortunately, Guido's claim that it doesn't work back then is about as convincing as the Steve Langasek's claim that it does work now. If we find it does break, we should document more clearly (or, perhaps, even fix it...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993173&group_id=5470 From noreply at sourceforge.net Mon Jul 19 19:01:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 19:01:54 2004 Subject: [Patches] [ python-Patches-984654 ] socket module does not support AF_NETLINK Message-ID: Patches item #984654, was opened at 2004-07-03 18:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket module does not support AF_NETLINK Initial Comment: [forwarded from http://bugs.debian.org/257444] The socket module is missing the AF_NETLINK constant and the associated support, as well as a whole bunch of others. The list of missing address families seems to be: #define AF_ATMPVC 8 /* ATM PVCs */ #define AF_DECnet 12 /* Reserved for DECnet project */ #define AF_NETBEUI 13 /* Reserved for 802.2LLC project*/ #define AF_SECURITY 14 /* Security callback pseudo AF */ #define AF_KEY 15 /* PF_KEY key management API */ #define AF_NETLINK 16 #define AF_ROUTE AF_NETLINK /* Alias to emulate 4.4BSD */ #define AF_ASH 18 /* Ash */ #define AF_ECONET 19 /* Acorn Econet */ #define AF_ATMSVC 20 /* ATM SVCs */ #define AF_SNA 22 /* Linux SNA Project (nutters!) */ #define AF_IRDA 23 /* IRDA sockets */ #define AF_PPPOX 24 /* PPPoX sockets */ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC */ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-19 19:01 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as socketmodule.c 1.296. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-17 10:13 Message: Logged In: YES user_id=21627 I think the request is about adding the constants if the system offers them; I have no problems with that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 16:45 Message: Logged In: YES user_id=11375 This is really a feature request. It would be easy to add the various AF_* constants to the module, but truly supporting all these new families requires appropriate changes to the makesockaddr(), getsockaddrarg(), and getsockaddrlen() functions in Modules/socketmodule.c. I don't know what the address strings/objects for the various families look like, and have no idea where to find such information. If AF_NETLINK is important, we can certainly try to implement that one family. Something obscure like AF_SNA is unlikely to ever be supported in the absence of a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=984654&group_id=5470 From noreply at sourceforge.net Mon Jul 19 19:09:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 19:09:45 2004 Subject: [Patches] [ python-Patches-993943 ] Unicode in distutils.core.setup() Message-ID: Patches item #993943, was opened at 2004-07-19 19:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Thomas Heller (theller) Summary: Unicode in distutils.core.setup() Initial Comment: distutils.core.setup() should support Unicode objects for the author argument and others and properly show them in the Windows installer (currently repr() is used one the value, which leads to strange results. Attached is Thomas Heller's patch for that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 From noreply at sourceforge.net Mon Jul 19 19:14:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 19:14:24 2004 Subject: [Patches] [ python-Patches-993943 ] Unicode in distutils.core.setup() Message-ID: Patches item #993943, was opened at 2004-07-19 19:09 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Thomas Heller (theller) Summary: Unicode in distutils.core.setup() Initial Comment: distutils.core.setup() should support Unicode objects for the author argument and others and properly show them in the Windows installer (currently repr() is used one the value, which leads to strange results. Attached is Thomas Heller's patch for that. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-07-19 19:14 Message: Logged In: YES user_id=89016 Testing this patch doesn't work for me, but this seems to be more a problem of the build process than of this patch. Updating to CVS head on Windows, compiling the pythoncore and python target in Visual C++ .net Standard (without applying the patch) and running a setup script with this python.exe gives me the following: \Python-current\dist\src\PCbuild\python setup.py bdist -- formats=wininst running bdist running bdist_wininst running build running build_py Traceback (most recent call last): File "setup.py", line 50, in ? package_dir={"ll": ""} File "D:\Python-current\dist\src\lib\distutils\core.py", line 150, in setup dist.run_commands() File "D:\Python-current\dist\src\lib\distutils\dist.py", line 951, in run_commands self.run_command(cmd) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist.py", line 146, in run self.run_command(cmd_name) File "D:\Python-current\dist\src\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist_wininst.py", line 127, in run assert self.skip_build, "Should have already checked this" AssertionError: Should have already checked this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 From noreply at sourceforge.net Mon Jul 19 22:04:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 22:04:04 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 20: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=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Mon Jul 19 22:59:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 19 22:59:44 2004 Subject: [Patches] [ python-Patches-839496 ] SimpleHTTPServer reports wrong content-length for text files Message-ID: Patches item #839496, was opened at 2003-11-10 21:42 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer reports wrong content-length for text files Initial Comment: (Python 2.3.2 on Windows) SimpleHTTPServer reports the size of the file on disk as Content-Length. This works except for text files. If the content type starts with "text/" it is opening the file in 'text' mode rather than 'binary' mode. At least on Windows this causes newline translations, thereby making the actual size of the content transmitted *less* than the content-length! I don't know why SimpleHTTPServer is reading text files with text mode. The included patch removes this distinction so all files are opened in binary mode (and, also on windows, the actual size transmitted is the same as the reported content-length). --Irmen de Jong ---------------------------------------------------------------------- >Comment By: Irmen de Jong (irmen) Date: 2004-07-19 22:59 Message: Logged In: YES user_id=129426 Hm, perhaps the easy way out (see my patch) is not the best solution: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 It seems it's best to convert text responses to CR LF format? If we should do this, we must somehow 're-calculate' the content-length after the CR LF conversion. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-06-06 13:18 Message: Logged In: YES user_id=129426 The attached httptest.zip contains a test scenario. When run on windows, it will show the problem. First start 'startserver.py' and then from the same directory run test.py. I get this: [E:\temp\httptest]python test.py The reported content-length is: 1047 bytes The real filesize is: 1047 bytes The data I actually received from the httpserver is: 1028 bytes ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-31 18:51 Message: Logged In: YES user_id=129426 The attached trivial patch removes the special case for text files. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-05-13 13:21 Message: Logged In: YES user_id=129426 This bug is also still present in the SimpleHTTPServer.py from Python 2.3.3 (and in the current CVS version, too). Is there a reason why it treats text files differently? If so, then at least the reported content-length must be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=839496&group_id=5470 From rowedn at tic.ac.uk Tue Jul 20 01:00:24 2004 From: rowedn at tic.ac.uk (rowedn@tic.ac.uk) Date: Tue Jul 20 01:01:09 2004 Subject: [Patches] $39757 Message-ID: <0dd701c46de4$9e24b665$8cb8d3fd@aplamps.co.uk> Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- argument xml:lang examples incomplete contains group user's list Japanese dates HTTP but such then resource procedure Java even its mechanisms produced written fallback repeated From bryn at herewegoherewego.com Tue Jul 20 05:05:47 2004 From: bryn at herewegoherewego.com (Unfriendly Q. Theodora) Date: Tue Jul 20 05:20:20 2004 Subject: [Patches] Best rates on medication, shipping worldwide! Message-ID: <111101c46e06$ef6faa80$70d8ae2d@herewegoherewego.com> What are the washing instructions? How sweet it is to love, and to be dissolved, and as it were to bathe myself in thy love. We need two kinds of acquaintances, one to complain to, while to the others we boast. http://clinanthia.haksam.com/3/ You are within God. God is within you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040719/17b65986/attachment.html From design at buggeration.com Tue Jul 20 13:45:57 2004 From: design at buggeration.com (Mob P. Scrimmage) Date: Tue Jul 20 14:00:31 2004 Subject: [Patches] Exceptional deals for medication on our site. Message-ID: <001101c46e4f$d044fd6f$f9bbd91c@buggeration.com> Evening, landlord :) Art the end result of perception, wisdom, intelligence, discipline, hard work, passion, luck, accident, and coincidence. Who loves, raves. http://doglegging.maielovewi.com/3/ I knew what my job was it was to go out and meet the people and love them. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040720/f9a402da/attachment.htm From noreply at sourceforge.net Tue Jul 20 14:40:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 20 14:40:22 2004 Subject: [Patches] [ python-Patches-993943 ] Unicode in distutils.core.setup() Message-ID: Patches item #993943, was opened at 2004-07-19 19:09 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Thomas Heller (theller) Summary: Unicode in distutils.core.setup() Initial Comment: distutils.core.setup() should support Unicode objects for the author argument and others and properly show them in the Windows installer (currently repr() is used one the value, which leads to strange results. Attached is Thomas Heller's patch for that. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-20 14:40 Message: Logged In: YES user_id=11105 Walter, I cannot reproduce this behaviour, even with the ansistyle setup script. And you're the only one reporting this. Do you have anything special (setup.cfg is the only on that comes to mind)? Do you get the same from the 'python setup.py bdist_wininst' command? How does python-2.4a1 from python.org behave for you? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-07-19 19:14 Message: Logged In: YES user_id=89016 Testing this patch doesn't work for me, but this seems to be more a problem of the build process than of this patch. Updating to CVS head on Windows, compiling the pythoncore and python target in Visual C++ .net Standard (without applying the patch) and running a setup script with this python.exe gives me the following: \Python-current\dist\src\PCbuild\python setup.py bdist -- formats=wininst running bdist running bdist_wininst running build running build_py Traceback (most recent call last): File "setup.py", line 50, in ? package_dir={"ll": ""} File "D:\Python-current\dist\src\lib\distutils\core.py", line 150, in setup dist.run_commands() File "D:\Python-current\dist\src\lib\distutils\dist.py", line 951, in run_commands self.run_command(cmd) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist.py", line 146, in run self.run_command(cmd_name) File "D:\Python-current\dist\src\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist_wininst.py", line 127, in run assert self.skip_build, "Should have already checked this" AssertionError: Should have already checked this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 From noreply at sourceforge.net Tue Jul 20 17:46:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 20 17:46:23 2004 Subject: [Patches] [ python-Patches-994595 ] HTTP basic authentication problem Message-ID: Patches item #994595, was opened at 2004-07-20 16: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=994595&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Catalin Marinas (c_marinas) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP basic authentication problem Initial Comment: The regular expression matching in the AbstractBasicAuthHandler.http_error_auth_reqed() function in the urllib2 module doesn't work if the authorization string returned by the server contains one or more words in front of 'Basic realm="..."'. The patch changes the rx.match() to rx.search(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 From noreply at sourceforge.net Tue Jul 20 23:55:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 20 23:56:00 2004 Subject: [Patches] [ python-Patches-846659 ] fix for bug #812325 (tarfile violates bufsize) Message-ID: Patches item #846659, was opened at 2003-11-21 10:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 Category: Library (Lib) >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: Neal Norwitz (nnorwitz) Summary: fix for bug #812325 (tarfile violates bufsize) Initial Comment: The attached patch fixes an error in the code for GNU longname/longlink creation. An additional GNU header block is added to the tar file but not summed up to the internal counter (self.offset). On close() the zeropadding is miscalculated which leads to blocksize violation at the end of the archive. I had a conversation with Johan Fredrik ?hman (johanfo) who reported bug #812325 and he told me that my patch solved his problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 17:55 Message: Logged In: YES user_id=33168 Sorry it took so long. Checking in: * Lib/tarfile.py; 1.12 * Lib/test/test_tarfile.py; 1.12 * Misc/NEWS; 1.1047 ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-12 04:49 Message: Logged In: YES user_id=642936 Are there any chances to have this patch (and probably the other pending tarfile patches) applied for the next release? ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2004-02-25 14:12 Message: Logged In: YES user_id=642936 This is now the complete final patchset: - fixes bug #812325. - fixes the second bug in _create_gnulong() I discovered. - adds a testcase for GNUlong extensions. - reverses a patch by A.M. Kuchling which addresses bug #812325 but which is unnecessary. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-21 23:35 Message: Logged In: YES user_id=33168 More tests are always good. :-) I'll try to take a look at this later, or if someone else checks in that's fine too. Also, if I don't get to this, feel free to add the tests to this patch. Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2003-12-16 09:18 Message: Logged In: YES user_id=642936 I must admit, that longnames/longlinks haven't been covered at all by the test suite until now. Shame on me :-( So I'm working on some general testcases right now. While writing the tests, I discovered yet another bug in the longname creation code that must be fixed. Shame on me again :-(( If you agree, Neal, I will submit a second patch that eliminates this new bug and includes a complete set of test cases for both bugs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 10:14 Message: Logged In: YES user_id=33168 Lars, could you add a test case for this as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 From noreply at sourceforge.net Wed Jul 21 00:10:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 00:10:39 2004 Subject: [Patches] [ python-Patches-916874 ] fix for bug #857297 (tarfile and hardlinks) Message-ID: Patches item #916874, was opened at 2004-03-15 15:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=916874&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: Neal Norwitz (nnorwitz) Summary: fix for bug #857297 (tarfile and hardlinks) Initial Comment: Included is a patch that fixes the extraction of hardlinks in tarfile.py (bug #857297) and a testcase. Until now tarfile.py extracted hardlinks the same way as symlinks which worked under certain circumstances: if the hardlink source is accessible from the current working directory everything is fine, but if you choose to extract it to a different location it won't work. That particular code in tarfile.py dates back to my good old windoze days where my understanding of unix filesystem basics was not as profound as it is today :-) The testcase probably needs some attention regarding portability. (On platforms that do not have os.link() it is skipped completely.) Trying to extract a hardlink and testing for its existence afterwards is no option here, because it doesn't necessarily need to be tarfile.py's fault if this doesn't work. There are many different conditions involved, especially the filesystem the test is made on. My current solution is that the testcase tries to create a link and if it gets an ENOENT (which means the link's source file cannot be found) it fails. All other EnvironmentErrors are ignored. Interestingly this testcase even works on a FAT32 filesystem (on my Linux box) - if the link's source cannot be found there is an ENOENT (and the test fails as it should), and if it can be found there is an EPERM which is ignored. IMO all this is a bit too much black magic and maybe the testcase introduces more problems than it actually solves, so feel free to throw it away. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 18:10 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Lib/tarfile.py; 1.13 * Lib/test/test_tarfile.py; 1.13 * Misc/NEWS; 1.1048 Perhaps this should be backported to 2.3? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-03-15 21:57 Message: Logged In: YES user_id=33168 Lars, I just wanted to say thanks for this patch and the other. I hope to get around to them soon. But it may have to wait until after pycon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=916874&group_id=5470 From noreply at sourceforge.net Wed Jul 21 00:28:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 00:28:12 2004 Subject: [Patches] [ python-Patches-918101 ] tarfile.py enhancements Message-ID: Patches item #918101, was opened at 2004-03-17 10:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py enhancements Initial Comment: I still develop tarfile.py sporadically on a separate branch (http://www.gustaebel.de/lars/tarfile/), and so there are two features from this branch that I'd like to propose for inclusion in Python's tarfile.py: 1. Overcoming the 8GB file size limit (8GB-limit.patch) At the moment it is not possible to add files to a tar archive that exceed 8GB size. Although this is POSIX compliant, GNU tar offers an extension header for largefiles that encodes file sizes in an 88-bit number instead of the common 11-digits octal number. Like all other GNU extensions in tarfile.py, this feature is turned on and off using the TarFile.posix attribute. 2. Automatic compression detection for the stream interface (stream-detect-compr.patch) tarfile.py's stream interface (which can be used to access tape devices or simply read a tar from stdin) is a bit difficult to use because it's not able to detect whether an archive is compressed or not. Compression has to be explicitly specified using mode ("r|", "r|gz", "r|bz2"). The patch introduces a fourth mode "r|*" that makes automatic detection possible. Both patches are not vitally important, but especially the 8GB-patch is useful IMO. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 18:28 Message: Logged In: YES user_id=33168 I checked in the 8GB limit patch. Lib/tarfile.py 1.14. I didn't check in the stream patch for 2 reasons: 1) I don't know the need. Is this common? I've never heard of it. 2) The type parameter name was changed to comtype. I wasn't sure if this was necessary. It potentially (albeit unlikely) could break a program. I'm not concerned about changing the name of attribute. Lars, can you provide a good reason to add this part of the patch? If it's not likely to be used, I don't think it should be added. If it is added, there should also be a test. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 From noreply at sourceforge.net Wed Jul 21 00:31:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 00:31:11 2004 Subject: [Patches] [ python-Patches-918101 ] tarfile.py enhancements Message-ID: Patches item #918101, was opened at 2004-03-17 10:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 Category: Library (Lib) >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py enhancements Initial Comment: I still develop tarfile.py sporadically on a separate branch (http://www.gustaebel.de/lars/tarfile/), and so there are two features from this branch that I'd like to propose for inclusion in Python's tarfile.py: 1. Overcoming the 8GB file size limit (8GB-limit.patch) At the moment it is not possible to add files to a tar archive that exceed 8GB size. Although this is POSIX compliant, GNU tar offers an extension header for largefiles that encodes file sizes in an 88-bit number instead of the common 11-digits octal number. Like all other GNU extensions in tarfile.py, this feature is turned on and off using the TarFile.posix attribute. 2. Automatic compression detection for the stream interface (stream-detect-compr.patch) tarfile.py's stream interface (which can be used to access tape devices or simply read a tar from stdin) is a bit difficult to use because it's not able to detect whether an archive is compressed or not. Compression has to be explicitly specified using mode ("r|", "r|gz", "r|bz2"). The patch introduces a fourth mode "r|*" that makes automatic detection possible. Both patches are not vitally important, but especially the 8GB-patch is useful IMO. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 18:31 Message: Logged In: YES user_id=33168 Lars, could you look at bug 949052 and provide any guidance? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 18:28 Message: Logged In: YES user_id=33168 I checked in the 8GB limit patch. Lib/tarfile.py 1.14. I didn't check in the stream patch for 2 reasons: 1) I don't know the need. Is this common? I've never heard of it. 2) The type parameter name was changed to comtype. I wasn't sure if this was necessary. It potentially (albeit unlikely) could break a program. I'm not concerned about changing the name of attribute. Lars, can you provide a good reason to add this part of the patch? If it's not likely to be used, I don't think it should be added. If it is added, there should also be a test. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 From k.byrd_nw at eightdegrees.com.au Wed Jul 21 02:03:35 2004 From: k.byrd_nw at eightdegrees.com.au (k.byrd_nw@eightdegrees.com.au) Date: Wed Jul 21 02:07:34 2004 Subject: [Patches] $47258 Message-ID: <5a5101c46eb6$cd8ab131$cb0234e5@engevix-sc.com.br> Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- particular zones cannot interaction What this implement like Usage intended This segments then greater reflection lesser fallback documents NET operation zone mistake internationalization lives From noreply at sourceforge.net Wed Jul 21 05:01:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 05:01:38 2004 Subject: [Patches] [ python-Patches-993062 ] cgi.parse_qs: make an empty string give {}, like in 2.3. Message-ID: Patches item #993062, was opened at 2004-07-17 16:06 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993062&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Richie Hindle (richiehindle) Assigned to: Brett Cannon (bcannon) Summary: cgi.parse_qs: make an empty string give {}, like in 2.3. Initial Comment: Prior to 2.4, cgi.parse_qs("", keep_blank_values=True) returned {}. It now returns {'': ['']}. This patch restores the old behaviour without breaking the edit that introduced it, namely that parse_qs("pog", keep_blank_values=True) should return {'pog': ['']}. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-07-20 20:01 Message: Logged In: YES user_id=357491 Neil fixed this so as to return an empty dict to deal with bug #990307; essentially this is a dup report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-18 18:24 Message: Logged In: YES user_id=33168 Brett, you changed the keep_blank_values, do you agree with this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993062&group_id=5470 From noreply at sourceforge.net Wed Jul 21 09:54:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 09:54:35 2004 Subject: [Patches] [ python-Patches-918101 ] tarfile.py enhancements Message-ID: Patches item #918101, was opened at 2004-03-17 16:59 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py enhancements Initial Comment: I still develop tarfile.py sporadically on a separate branch (http://www.gustaebel.de/lars/tarfile/), and so there are two features from this branch that I'd like to propose for inclusion in Python's tarfile.py: 1. Overcoming the 8GB file size limit (8GB-limit.patch) At the moment it is not possible to add files to a tar archive that exceed 8GB size. Although this is POSIX compliant, GNU tar offers an extension header for largefiles that encodes file sizes in an 88-bit number instead of the common 11-digits octal number. Like all other GNU extensions in tarfile.py, this feature is turned on and off using the TarFile.posix attribute. 2. Automatic compression detection for the stream interface (stream-detect-compr.patch) tarfile.py's stream interface (which can be used to access tape devices or simply read a tar from stdin) is a bit difficult to use because it's not able to detect whether an archive is compressed or not. Compression has to be explicitly specified using mode ("r|", "r|gz", "r|bz2"). The patch introduces a fourth mode "r|*" that makes automatic detection possible. Both patches are not vitally important, but especially the 8GB-patch is useful IMO. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-21 09:54 Message: Logged In: YES user_id=642936 tarfile.py's stream interface must be used if the user wants to read an archive that is not a seekable file, e.g. stdin or a tape device. ATM, it is the user's job to find out whether the stream is compressed (mode="r|gz" or "r|bz2") or uncompressed (mode="r|"), which makes the stream interface kind of awkward and unusable for many users. The patch introduces an additional mode "r|*" which does this job. I admit it's just a convenience thing but I think the stream interface is somehow too complicated without it. The reason why I changed the "type" argument to "comptype" was just that the TarFile class uses "comptype" and the _Stream class uses "type" for the same thing. It doesn't need to be changed. You're absolute right about the testcase. I had enough time to write one ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-21 00:31 Message: Logged In: YES user_id=33168 Lars, could you look at bug 949052 and provide any guidance? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-21 00:28 Message: Logged In: YES user_id=33168 I checked in the 8GB limit patch. Lib/tarfile.py 1.14. I didn't check in the stream patch for 2 reasons: 1) I don't know the need. Is this common? I've never heard of it. 2) The type parameter name was changed to comtype. I wasn't sure if this was necessary. It potentially (albeit unlikely) could break a program. I'm not concerned about changing the name of attribute. Lars, can you provide a good reason to add this part of the patch? If it's not likely to be used, I don't think it should be added. If it is added, there should also be a test. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 From noreply at sourceforge.net Wed Jul 21 12:10:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 12:10:35 2004 Subject: [Patches] [ python-Patches-995126 ] tarfile.py fix for bug #949052 Message-ID: Patches item #995126, was opened at 2004-07-21 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=995126&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for bug #949052 Initial Comment: Contained are two patches: eisenmann.patch - a modified version of OP Simon Eisenmann's patch that prevents tarfile.py from setting the size attribute for directory members. posix.patch - Simon brought up another issue: tarfile.py operates in posix mode by default. My original idea behind this was that it provides a higher portability to other archiver programs (if they adhere to the posix standard). Simon states that e.g. WinZip is not able to read posix-compliant tar archives but those with GNU extensions. So I think the idea of being as portable as possible has proven false. GNU tar format is a quasi-standard. The second issue is that posix mode imposes several limits - on pathname lengths in particular - since GNU extensions are not allowed. For the average user, this must be annoying, he does not care about posix and all this portability stuff, he simply wants to add files regardless of the length of their pathnames. But he first has to search the docs and set TarFile's posix attribute to False to enable GNU extensions. Even worse is that e.g. backup scripts that run flawlessly for months can suddenly fail just because there's a new file with a long pathname that posix mode cannot handle. To cut a long story short, I second Simon's proposal. Since I contributed tarfile.py to Python's stdlib I had the feeling I had made the wrong decision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995126&group_id=5470 From noreply at sourceforge.net Wed Jul 21 14:05:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 14:05:32 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 16:04 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2004-07-21 08:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Wed Jul 21 14:46:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 14:46:07 2004 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 23:25 Message generated for change (Comment added) made by colander_man You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 08:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Wed Jul 21 14:55:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 14:56:22 2004 Subject: [Patches] [ python-Patches-918101 ] tarfile.py enhancements Message-ID: Patches item #918101, was opened at 2004-03-17 16:59 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py enhancements Initial Comment: I still develop tarfile.py sporadically on a separate branch (http://www.gustaebel.de/lars/tarfile/), and so there are two features from this branch that I'd like to propose for inclusion in Python's tarfile.py: 1. Overcoming the 8GB file size limit (8GB-limit.patch) At the moment it is not possible to add files to a tar archive that exceed 8GB size. Although this is POSIX compliant, GNU tar offers an extension header for largefiles that encodes file sizes in an 88-bit number instead of the common 11-digits octal number. Like all other GNU extensions in tarfile.py, this feature is turned on and off using the TarFile.posix attribute. 2. Automatic compression detection for the stream interface (stream-detect-compr.patch) tarfile.py's stream interface (which can be used to access tape devices or simply read a tar from stdin) is a bit difficult to use because it's not able to detect whether an archive is compressed or not. Compression has to be explicitly specified using mode ("r|", "r|gz", "r|bz2"). The patch introduces a fourth mode "r|*" that makes automatic detection possible. Both patches are not vitally important, but especially the 8GB-patch is useful IMO. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-21 14:55 Message: Logged In: YES user_id=642936 I just created tests for the stream-detect-compr.patch, attached as test.patch. BTW, I examined bug #949052, and opened a patch (#995126). ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2004-07-21 09:54 Message: Logged In: YES user_id=642936 tarfile.py's stream interface must be used if the user wants to read an archive that is not a seekable file, e.g. stdin or a tape device. ATM, it is the user's job to find out whether the stream is compressed (mode="r|gz" or "r|bz2") or uncompressed (mode="r|"), which makes the stream interface kind of awkward and unusable for many users. The patch introduces an additional mode "r|*" which does this job. I admit it's just a convenience thing but I think the stream interface is somehow too complicated without it. The reason why I changed the "type" argument to "comptype" was just that the TarFile class uses "comptype" and the _Stream class uses "type" for the same thing. It doesn't need to be changed. You're absolute right about the testcase. I had enough time to write one ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-21 00:31 Message: Logged In: YES user_id=33168 Lars, could you look at bug 949052 and provide any guidance? Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-21 00:28 Message: Logged In: YES user_id=33168 I checked in the 8GB limit patch. Lib/tarfile.py 1.14. I didn't check in the stream patch for 2 reasons: 1) I don't know the need. Is this common? I've never heard of it. 2) The type parameter name was changed to comtype. I wasn't sure if this was necessary. It potentially (albeit unlikely) could break a program. I'm not concerned about changing the name of attribute. Lars, can you provide a good reason to add this part of the patch? If it's not likely to be used, I don't think it should be added. If it is added, there should also be a test. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=918101&group_id=5470 From noreply at sourceforge.net Wed Jul 21 15:19:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 15:19:03 2004 Subject: [Patches] [ python-Patches-995225 ] tarfile.py fix for bug #990325 Message-ID: Patches item #995225, was opened at 2004-07-21 15: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=995225&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for bug #990325 Initial Comment: attached is a new testtar.tar that does not contain CVS keywords in its data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995225&group_id=5470 From noreply at sourceforge.net Wed Jul 21 17:52:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 17:52:56 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 15:04 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-21 10:52 Message: Logged In: YES user_id=2772 GNU find also uses os.chdir() to descend into the directory hierarchy, which means that all its "stat" calls use filenames within the current directory. Clearly, python's os.walk can't do this, because the working directory is shared among threads. Disaster would result. But, anyway, this is another reason that os.walk is slower than find. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 07:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Wed Jul 21 19:16:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 19:16:44 2004 Subject: [Patches] [ python-Patches-993943 ] Unicode in distutils.core.setup() Message-ID: Patches item #993943, was opened at 2004-07-19 19:09 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Thomas Heller (theller) Summary: Unicode in distutils.core.setup() Initial Comment: distutils.core.setup() should support Unicode objects for the author argument and others and properly show them in the Windows installer (currently repr() is used one the value, which leads to strange results. Attached is Thomas Heller's patch for that. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-07-21 19:16 Message: Logged In: YES user_id=89016 Now it's working perfectly with Python-2.4a1 (the CVS version complains about the missing zlib module). It works both with "setup.py bdist --formats=wininst" and "setup.py bdist_wininst". Maybe my Windows box required a few more reboots after the Visual C++ installation? The resulting Windows installer looks good, so I guess you can check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-20 14:40 Message: Logged In: YES user_id=11105 Walter, I cannot reproduce this behaviour, even with the ansistyle setup script. And you're the only one reporting this. Do you have anything special (setup.cfg is the only on that comes to mind)? Do you get the same from the 'python setup.py bdist_wininst' command? How does python-2.4a1 from python.org behave for you? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-07-19 19:14 Message: Logged In: YES user_id=89016 Testing this patch doesn't work for me, but this seems to be more a problem of the build process than of this patch. Updating to CVS head on Windows, compiling the pythoncore and python target in Visual C++ .net Standard (without applying the patch) and running a setup script with this python.exe gives me the following: \Python-current\dist\src\PCbuild\python setup.py bdist -- formats=wininst running bdist running bdist_wininst running build running build_py Traceback (most recent call last): File "setup.py", line 50, in ? package_dir={"ll": ""} File "D:\Python-current\dist\src\lib\distutils\core.py", line 150, in setup dist.run_commands() File "D:\Python-current\dist\src\lib\distutils\dist.py", line 951, in run_commands self.run_command(cmd) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist.py", line 146, in run self.run_command(cmd_name) File "D:\Python-current\dist\src\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist_wininst.py", line 127, in run assert self.skip_build, "Should have already checked this" AssertionError: Should have already checked this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 From noreply at sourceforge.net Wed Jul 21 21:29:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 21:29:07 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 04:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-21 15:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 07:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 23:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 04:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Wed Jul 21 23:37:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jul 21 23:38:12 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 20:04 Message generated for change (Comment added) made by felixlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- >Comment By: Felix Lee (felixlee) Date: 2004-07-21 21:37 Message: Logged In: YES user_id=77867 the chdir() optimization seems to be mostly insignificant on modern systems (I'm doing timings on linux 2.6). perl will do chdir too, and it's only slightly faster than python if nlinks gets used, and the amount of system time used is pretty indistinguishable among all the versions. I suspect ram is cheap enough that large dir->inode caches are easy and fast. the remaining difference in speed between GNU find and a perl or python version is in user time, and I think most of that can be attributed to interpreter overhead. crossing a function call boundary 100,000 times is hard to make fast in any interpreted language. the nlink optimization is significant, I think that's worth doing, but I don't think any other optimization is. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-21 15:52 Message: Logged In: YES user_id=2772 GNU find also uses os.chdir() to descend into the directory hierarchy, which means that all its "stat" calls use filenames within the current directory. Clearly, python's os.walk can't do this, because the working directory is shared among threads. Disaster would result. But, anyway, this is another reason that os.walk is slower than find. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 12:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Thu Jul 22 00:35:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 00:35:25 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 20:04 Message generated for change (Comment added) made by felixlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- >Comment By: Felix Lee (felixlee) Date: 2004-07-21 22:35 Message: Logged In: YES user_id=77867 thinking about it some more, a separate function is probably a good idea. at the moment I'm calling it 'lwalk' (analogy to stat/lstat). it should be usable on systems without links too. I'll attach it in a day or two. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-21 21:37 Message: Logged In: YES user_id=77867 the chdir() optimization seems to be mostly insignificant on modern systems (I'm doing timings on linux 2.6). perl will do chdir too, and it's only slightly faster than python if nlinks gets used, and the amount of system time used is pretty indistinguishable among all the versions. I suspect ram is cheap enough that large dir->inode caches are easy and fast. the remaining difference in speed between GNU find and a perl or python version is in user time, and I think most of that can be attributed to interpreter overhead. crossing a function call boundary 100,000 times is hard to make fast in any interpreted language. the nlink optimization is significant, I think that's worth doing, but I don't think any other optimization is. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-21 15:52 Message: Logged In: YES user_id=2772 GNU find also uses os.chdir() to descend into the directory hierarchy, which means that all its "stat" calls use filenames within the current directory. Clearly, python's os.walk can't do this, because the working directory is shared among threads. Disaster would result. But, anyway, this is another reason that os.walk is slower than find. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 12:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Thu Jul 22 03:04:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 03:04:56 2004 Subject: [Patches] [ python-Patches-995225 ] tarfile.py fix for bug #990325 Message-ID: Patches item #995225, was opened at 2004-07-21 09:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995225&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for bug #990325 Initial Comment: attached is a new testtar.tar that does not contain CVS keywords in its data. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-07-21 21:04 Message: Logged In: YES user_id=31435 Thank you, Lars! Checked in, Lib/test/testtar.tar; new revision: 1.2 Misc/NEWS; new revision: 1.1050 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995225&group_id=5470 From wdewittmz at actrix.gen.nz Thu Jul 22 08:22:50 2004 From: wdewittmz at actrix.gen.nz (wdewittmz@actrix.gen.nz) Date: Thu Jul 22 08:27:17 2004 Subject: [Patches] $47258 Message-ID: Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- populate between examples setting [Web objects object in if provide marks impossible works Unlike regard populate Patent accordance formats an writes their colors publish From noreply at sourceforge.net Thu Jul 22 09:20:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 09:20:28 2004 Subject: [Patches] [ python-Patches-995740 ] fix for title case bug: #995422 Message-ID: Patches item #995740, was opened at 2004-07-22 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995740&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Baris Metin (tbmetin) Assigned to: Nobody/Anonymous (nobody) Summary: fix for title case bug: #995422 Initial Comment: Patch offers a solution for bug #995422. The basic idea in modification is changing the case in specified situations We must define the situations which changes the case. A simple aproach can be considering a case change if we are dealing with the first character of the string or the previous characters is a whitespace/punctuation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995740&group_id=5470 From noreply at sourceforge.net Thu Jul 22 10:25:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 10:25:23 2004 Subject: [Patches] [ python-Patches-995766 ] Keyword argument support in cPickle Message-ID: Patches item #995766, was opened at 2004-07-22 08: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=995766&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword argument support in cPickle Initial Comment: Add keyword argument support to the "dump", "dumps", and "Pickler" callables in the cPickle module. This provides better API compatibility with the pure-Python pickle module. There are several other differences, but this one is probably the most user-visible and likely to be noticed. And it's easy to fix! The callables chosen are those that take multiple arguments. This patch addresses bug #888594 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 From noreply at sourceforge.net Thu Jul 22 10:39:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 10:39:26 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-07-22 01:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 12:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Thu Jul 22 10:57:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 10:57:36 2004 Subject: [Patches] [ python-Patches-995782 ] Skipped test expectations for freebsd5 Message-ID: Patches item #995782, was opened at 2004-07-22 08:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995782&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Skipped test expectations for freebsd5 Initial Comment: Add list of tests that we expect to skip on freebsd5. Looking over the tests for freebsd4, it seems that they would apply on any version of FreeBSD, so the list is not duplicated explicitly. If in the future we find that the list usually doesn't differ between different versions of the same system, it might make sense to support patterns like 'freebsd*' instead of listing each version explicitly. FWIW, all tests pass on a July 3rd -CURRENT ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995782&group_id=5470 From noreply at sourceforge.net Thu Jul 22 16:14:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 16:14:27 2004 Subject: [Patches] [ python-Patches-995939 ] Avoid calling tp_compare with different types Message-ID: Patches item #995939, was opened at 2004-07-22 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid calling tp_compare with different types Initial Comment: C implementations of the tp_compare slot usually expect both of their arguments to have the type for which that slot is defined (this isn't documented anywhere that I can find, but many core types assume this, and extension authors are likely to do the same). A problem occurs if a user-defined nb_coerce slot (__coerce__) returns objects with different types. Avoid the problem by refusing to call a non-Python tp_compare unless the arguments have the same type. Indiscriminately calling tp_compare with different types is wrong as long as there are implementations that don't check the type of the second argument, but Python implementations should be allowed to receive a different type. Other options for fixing the problem: - Make PyNumber_CoerceEx require that the results have the same type. This would prevent a user-defined __coerce__ from communicating an arbitrary object to a user-defined __cmp__. Furthermore, there are uses for coerce besides comparison, and those uses might not require identical types. - Change tp_compare implementations to check the type of the second argument. This might be the most desirable long-term solution, but as I understand it, tp_richcompare is preferred over tp_compare for new code, and old (current) code is likely assuming that the types are the same. Addresses bug #980352 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470 From noreply at sourceforge.net Thu Jul 22 20:00:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 20:00:54 2004 Subject: [Patches] [ python-Patches-996067 ] hp-roman codec Message-ID: Patches item #996067, was opened at 2004-07-22 18:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: Nobody/Anonymous (nobody) Summary: hp-roman codec Initial Comment: This is a codec for hp-roman generated by munging data from dkuug.dk and running gencodec.py on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 From noreply at sourceforge.net Thu Jul 22 20:47:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 20:48:06 2004 Subject: [Patches] [ python-Patches-980500 ] gettext improvements Message-ID: Patches item #980500, was opened at 2004-06-27 02:17 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980500&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: gettext improvements Initial Comment: This patch implements the following gettext features, as discussed recently in python-dev: In _locale module: - bind_textdomain_codeset() binding In gettext module: - bind_textdomain_codeset() function - lgettext(), lngettext(), ldgettext(), ldngettext(), which return translated strings encoded in preferred system encoding, if bind_textdomain_codeset() was not used. - Added equivalent functionality in install() and translate() functions and catalog classes. - Documentated every change. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-07-22 18:47 Message: Logged In: YES user_id=7887 Thanks for reviewing it! Committed as: Modules/_localemodule.c: 2.48 Misc/NEWS: 1.1051 Lib/gettext.py: 1.24 Doc/lib/liblocale.tex: 1.37 Doc/lib/libgettext.tex: 1.25 pyconfig.h.in: 1.101 configure.in: 1.463 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-07-09 17:45 Message: Logged In: YES user_id=12800 Feedback provided to poster in pvt email. If those (minor) concerns are addressed, +1 on committing this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980500&group_id=5470 From noreply at sourceforge.net Thu Jul 22 22:48:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jul 22 22:48:27 2004 Subject: [Patches] [ python-Patches-996159 ] correct urllib2 header capitalization (fix for #994101) Message-ID: Patches item #996159, was opened at 2004-07-22 22: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=996159&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) Summary: correct urllib2 header capitalization (fix for #994101) Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". The former form is used throughout the module as well. This is incorrect. In this patch I've removed the capitalize() calls and used the correct form throughout both the module.and the tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996159&group_id=5470 From noreply at sourceforge.net Fri Jul 23 04:57:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 04:57:29 2004 Subject: [Patches] [ python-Patches-996316 ] New patch for Python 2.3 spec file. Message-ID: Patches item #996316, was opened at 2004-07-23 02:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: New patch for Python 2.3 spec file. Initial Comment: The changes in here probably can be used for the preliminary 2.4 spec file as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 From noreply at sourceforge.net Fri Jul 23 05:11:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 05:11:35 2004 Subject: [Patches] [ python-Patches-996316 ] New patch for Python 2.3 spec file. Message-ID: Patches item #996316, was opened at 2004-07-23 02:57 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: New patch for Python 2.3 spec file. Initial Comment: The changes in here probably can be used for the preliminary 2.4 spec file as well. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2004-07-23 03:11 Message: Logged In: YES user_id=81797 Grrr. sf.net seems to be having problems with file uploads. It's complaining that the file is <20 bytes or >256KB. Pick up the file from: ftp://ftp.python.org/python/2.3.4/rpms/python-spec-2.3.4-3.patch Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 From josefina_reynolds_jb at ticex.ge Fri Jul 23 07:41:11 2004 From: josefina_reynolds_jb at ticex.ge (josefina_reynolds_jb@ticex.ge) Date: Fri Jul 23 07:42:07 2004 Subject: [Patches] $17168 Message-ID: <66a201c47077$5917a363$8d55ccb1@tran-sig-ma.cz> Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- location There Tax even under Semantics: mechanism distinction with require allow correlate distinct amended When These descriptions sending Distinguishing creating Identifiers:: than own categories From noreply at sourceforge.net Fri Jul 23 12:00:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 12:00:42 2004 Subject: [Patches] [ python-Patches-996067 ] hp-roman codec Message-ID: Patches item #996067, was opened at 2004-07-22 19:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) >Assigned to: M.-A. Lemburg (lemburg) Summary: hp-roman codec Initial Comment: This is a codec for hp-roman generated by munging data from dkuug.dk and running gencodec.py on it. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-23 11:00 Message: Logged In: YES user_id=6656 I think the copyright is a bit inaccurate :-) Also, does this do the right thing with unassigned bytes? I didn't think (eg) 0x80 represented a valid character in roman8, could be wrong. Otherwise, looks ok to me... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 From noreply at sourceforge.net Fri Jul 23 12:06:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 12:06:25 2004 Subject: [Patches] [ python-Patches-996067 ] hp-roman codec Message-ID: Patches item #996067, was opened at 2004-07-22 20:00 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: M.-A. Lemburg (lemburg) Summary: hp-roman codec Initial Comment: This is a codec for hp-roman generated by munging data from dkuug.dk and running gencodec.py on it. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 12:06 Message: Logged In: YES user_id=38388 Richard, could you pleaes remove the copyright notices from the file and instead add a reference and/or explanation of where and how you obtained the data used in the codec. I'll fix the gencodec.py and remove the copyright notices. I used that script to build the initial set of codecs as part of the CNRI contracted work -- while the script is (c) CNRI, the output certainly isn't anymore. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-23 12:00 Message: Logged In: YES user_id=6656 I think the copyright is a bit inaccurate :-) Also, does this do the right thing with unassigned bytes? I didn't think (eg) 0x80 represented a valid character in roman8, could be wrong. Otherwise, looks ok to me... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 From noreply at sourceforge.net Fri Jul 23 12:21:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 12:21:53 2004 Subject: [Patches] [ python-Patches-996067 ] hp-roman codec Message-ID: Patches item #996067, was opened at 2004-07-22 20:00 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: M.-A. Lemburg (lemburg) Summary: hp-roman codec Initial Comment: This is a codec for hp-roman generated by munging data from dkuug.dk and running gencodec.py on it. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 12:21 Message: Logged In: YES user_id=38388 One more thing: please also provide a list of common aliases for this codec. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 12:06 Message: Logged In: YES user_id=38388 Richard, could you pleaes remove the copyright notices from the file and instead add a reference and/or explanation of where and how you obtained the data used in the codec. I'll fix the gencodec.py and remove the copyright notices. I used that script to build the initial set of codecs as part of the CNRI contracted work -- while the script is (c) CNRI, the output certainly isn't anymore. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-23 12:00 Message: Logged In: YES user_id=6656 I think the copyright is a bit inaccurate :-) Also, does this do the right thing with unassigned bytes? I didn't think (eg) 0x80 represented a valid character in roman8, could be wrong. Otherwise, looks ok to me... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 From noreply at sourceforge.net Fri Jul 23 13:53:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 13:53:51 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 15:24:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 15:25:14 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 09:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 07:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 09:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 15:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 02:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 14:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 14:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 02:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 10:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 00:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 09:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 15:57:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 15:57:12 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 17:17:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 17:17:46 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 09:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 09:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 07:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 09:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 15:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 02:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 14:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 14:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 02:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 10:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 00:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 09:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 17:48:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 17:48:16 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-23 10:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 10:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 18:10:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 18:11:04 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 12:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 11:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 09:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 09:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 07:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 09:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 15:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 02:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 14:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 14:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 02:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 10:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 00:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 09:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 18:31:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 18:31:09 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 12:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 12:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 11:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 09:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 09:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 07:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 09:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 15:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 05:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 02:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 14:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 14:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 02:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 10:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-29 00:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 09:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Fri Jul 23 21:44:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 21:44:59 2004 Subject: [Patches] [ python-Patches-993943 ] Unicode in distutils.core.setup() Message-ID: Patches item #993943, was opened at 2004-07-19 19:09 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Thomas Heller (theller) Summary: Unicode in distutils.core.setup() Initial Comment: distutils.core.setup() should support Unicode objects for the author argument and others and properly show them in the Windows installer (currently repr() is used one the value, which leads to strange results. Attached is Thomas Heller's patch for that. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-07-23 21:44 Message: Logged In: YES user_id=11105 Fixed in bdist_wininst, rev 1.52. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-07-21 19:16 Message: Logged In: YES user_id=89016 Now it's working perfectly with Python-2.4a1 (the CVS version complains about the missing zlib module). It works both with "setup.py bdist --formats=wininst" and "setup.py bdist_wininst". Maybe my Windows box required a few more reboots after the Visual C++ installation? The resulting Windows installer looks good, so I guess you can check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-20 14:40 Message: Logged In: YES user_id=11105 Walter, I cannot reproduce this behaviour, even with the ansistyle setup script. And you're the only one reporting this. Do you have anything special (setup.cfg is the only on that comes to mind)? Do you get the same from the 'python setup.py bdist_wininst' command? How does python-2.4a1 from python.org behave for you? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-07-19 19:14 Message: Logged In: YES user_id=89016 Testing this patch doesn't work for me, but this seems to be more a problem of the build process than of this patch. Updating to CVS head on Windows, compiling the pythoncore and python target in Visual C++ .net Standard (without applying the patch) and running a setup script with this python.exe gives me the following: \Python-current\dist\src\PCbuild\python setup.py bdist -- formats=wininst running bdist running bdist_wininst running build running build_py Traceback (most recent call last): File "setup.py", line 50, in ? package_dir={"ll": ""} File "D:\Python-current\dist\src\lib\distutils\core.py", line 150, in setup dist.run_commands() File "D:\Python-current\dist\src\lib\distutils\dist.py", line 951, in run_commands self.run_command(cmd) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist.py", line 146, in run self.run_command(cmd_name) File "D:\Python-current\dist\src\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "D:\Python-current\dist\src\lib\distutils\dist.py", line 971, in run_command cmd_obj.run() File "D:\Python- current\dist\src\lib\distutils\command\bdist_wininst.py", line 127, in run assert self.skip_build, "Should have already checked this" AssertionError: Should have already checked this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=993943&group_id=5470 From noreply at sourceforge.net Fri Jul 23 22:01:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jul 23 22:01:44 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 15:50 Message generated for change (Comment added) made by asouzis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-23 13:01 Message: Logged In: YES user_id=57486 certainly you need to be able to access the templates and modify them. And should be documented too -- one of the first things i wanted to know is how can i customize the output. But a config object seems like conceptual clutter. keyword arguments can be ignored and are just as persistent if you use ** on a dict. few more suggestions: * the default font seems too large on both ie 6 and firefox (this is with 1200 x 800 screen resolution, so it'd be even larger at a lower resolution). * maybe the links column (t, f, n) should also be on the left -- often there are long lines and you need to scroll over to access it. * add class attributes to the two tables used in the templates and move their styles to there (except i believe that IE doesn't honor cellpadding/spacing styles in css) thanks ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 09:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 09:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 06:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 04:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 06:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 12:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 02:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 02:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-14 23:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 11:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 11:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-23 23:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 07:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 21:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 06:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Sat Jul 24 06:20:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 24 06:20:34 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-23 23:20 Message: Logged In: YES user_id=80475 To clarify, the private variables are just a way to move the defaults out of the class definition and give the OP more control over formatting: _legend = """
Legends
Colors
 Added 
Changed
Deleted
Links
(f)irst change
(n)ext change
(t)op
""" class HtmlDiff(object): file_template = _file_template styles = _styles linenum_template = _linenum_template table_template = _table_template legend = _legend def __init__(self,prefix=['from','to'], linejunk=None, . . . ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-23 15:01 Message: Logged In: YES user_id=57486 certainly you need to be able to access the templates and modify them. And should be documented too -- one of the first things i wanted to know is how can i customize the output. But a config object seems like conceptual clutter. keyword arguments can be ignored and are just as persistent if you use ** on a dict. few more suggestions: * the default font seems too large on both ie 6 and firefox (this is with 1200 x 800 screen resolution, so it'd be even larger at a lower resolution). * maybe the links column (t, f, n) should also be on the left -- often there are long lines and you need to scroll over to access it. * add class attributes to the two tables used in the templates and move their styles to there (except i believe that IE doesn't honor cellpadding/spacing styles in css) thanks ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 11:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 10:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 10:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Sat Jul 24 06:33:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 24 06:33:35 2004 Subject: [Patches] [ python-Patches-995740 ] fix for title case bug: #995422 Message-ID: Patches item #995740, was opened at 2004-07-22 02:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995740&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Baris Metin (tbmetin) Assigned to: Nobody/Anonymous (nobody) Summary: fix for title case bug: #995422 Initial Comment: Patch offers a solution for bug #995422. The basic idea in modification is changing the case in specified situations We must define the situations which changes the case. A simple aproach can be considering a case change if we are dealing with the first character of the string or the previous characters is a whitespace/punctuation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-23 23:33 Message: Logged In: YES user_id=80475 This patch should probably not be accepted. See the discussion on the original bug report. There are issues of international language conventions and backwards compatability. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995740&group_id=5470 From gabriel.bbergeronug at svente.de Sat Jul 24 13:03:39 2004 From: gabriel.bbergeronug at svente.de (gabriel.bbergeronug@svente.de) Date: Sat Jul 24 13:05:55 2004 Subject: [Patches] $85145 Message-ID: <763c01c4716d$3fe67e07$01db8ab5@euromedia.cz> Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- Content-Language mail programming difficult Claim(s) identical) reports often serve no target implemented while Publication version archive Simplified on without used objects When regard subject From noreply at sourceforge.net Sat Jul 24 17:29:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jul 24 17:29:49 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-24 10:29 Message: Logged In: YES user_id=995755 I will be implementing the following suggestions: Raymond 7/19 & 7/23 [all] Adam 7/17 [all] Adam 7/23 [partial, but I need feedback] - Can I get a recommended solution for the font issue? - I'll likely do the additional links column on the left - Why move the attributes to a class for the two tables? Unless the template issue (public/protected/private) is discussed further, I will assume everyone is in agreement or can live with Raymond's suggestion & clarification. I will not be implementing any changes to the API right now. I lean somewhat strong toward leaving the optional arguments as they are but this can be talked about further if anyone thinks there are strong arguments to the contrary. Thanks Raymond, Adam, Jim, and Neal for your latest comments. Unless I get further suggestions, expect the patch hopefully by the end of the weekend. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-23 23:20 Message: Logged In: YES user_id=80475 To clarify, the private variables are just a way to move the defaults out of the class definition and give the OP more control over formatting: _legend = """
Legends
Colors
 Added 
Changed
Deleted
Links
(f)irst change
(n)ext change
(t)op
""" class HtmlDiff(object): file_template = _file_template styles = _styles linenum_template = _linenum_template table_template = _table_template legend = _legend def __init__(self,prefix=['from','to'], linejunk=None, . . . ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-23 15:01 Message: Logged In: YES user_id=57486 certainly you need to be able to access the templates and modify them. And should be documented too -- one of the first things i wanted to know is how can i customize the output. But a config object seems like conceptual clutter. keyword arguments can be ignored and are just as persistent if you use ** on a dict. few more suggestions: * the default font seems too large on both ie 6 and firefox (this is with 1200 x 800 screen resolution, so it'd be even larger at a lower resolution). * maybe the links column (t, f, n) should also be on the left -- often there are long lines and you need to scroll over to access it. * add class attributes to the two tables used in the templates and move their styles to there (except i believe that IE doesn't honor cellpadding/spacing styles in css) thanks ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 11:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 10:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 10:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Sun Jul 25 00:52:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 00:52:55 2004 Subject: [Patches] [ python-Patches-997284 ] Allow pydoc to work with XP Themes (.manifest file) Message-ID: Patches item #997284, was opened at 2004-07-24 14: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=997284&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Allow pydoc to work with XP Themes (.manifest file) Initial Comment: In Python 2.3.4, if you run pydoc -g under Windows XP when one of the special XP theme manifest files has been defined for python.exe or pythonw.exe, pydoc will cause an access violation when it closes. One solution is obviously to get rid of the manifest files, but wxPython installs them by default and apps written with it work without a problem. So it would be nice if pydoc would also work, and it turns out it didn't take a big change. Attached is a patch which fixes the problem (at least on my system). I noticed that idle did not have the access violation problem, and so copied what it does in PyShell.main. It might be better to introduce a more general fix for Tkinter. The problem seems to be that Uxtheme.dll frees up some global data before all the windows have called CloseThemeData (at app shutdown). The AV seems to happen when a call to CloseThemeData (presumably in response to a WM_DESTROY message) passes a bad pointer to RtlEnterCriticalSection. Anyway, it seems that if you get the window handles destroyed earlier in shutdown, the problem is fixed. Perhaps there is some way to provide the Tkinter module with an atexit handler which would destroy any existing widgets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470 From noreply at sourceforge.net Sun Jul 25 06:33:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 06:33:25 2004 Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support Message-ID: Patches item #890203, was opened at 2004-02-04 15:30 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: DragonFly BSD support Initial Comment: I spent some time building a simple little patch that gets Python up and running under DragonFly BSD. At the moment, DragonFly (as a platform) is nearly identical to FreeBSD (from which is was forked), so the generated the patch was largely mechanical. I'll continue to make efforts to support Python on DragonFly should things become more complicated. The only known issue is a test case failure for test_fcntl. I don't know whether this failure is unique to DragonFly at this time. I'll investigate that soon. This patch is valid for DragonFly 1.0-CURRENT using either GCC 2.95.4 or GCC 3.3.3 20040126. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-07-25 13:33 Message: Logged In: YES user_id=55188 I got massive errors while compiling some extension modules. (DragonflyBSD 1.0A, python HEAD as of today) ld build/temp.dragonfly-1.0A-RELEASE-i386-2.4/dlmodule.o -L/usr/local/lib -o build/lib.dragonfly-1.0A-RELEASE-i386-2.4/dl.so /usr/libexec/binutils212/elf/ld: warning: cannot find entry symbol _start; defaulting to 08048074 build/temp.dragonfly-1.0A-RELEASE-i386-2.4/dlmodule.o: In function `dl_call': /home/perky/python/Modules/dlmodule.c:82: undefined reference to `PyTuple_Size' /home/perky/python/Modules/dlmodule.c:84: undefined reference to `PyExc_TypeError' /home/perky/python/Modules/dlmodule.c:84: undefined reference to `PyErr_SetString' /home/perky/python/Modules/dlmodule.c:87: undefined reference to `PyTuple_GetItem' /home/perky/python/Modules/dlmodule.c:88: undefined reference to `PyString_Type' /home/perky/python/Modules/dlmodule.c:88: undefined reference to `PyString_Type' /home/perky/python/Modules/dlmodule.c:88: undefined reference to `PyType_IsSubtype' ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-03-15 11:43 Message: Logged In: YES user_id=485579 The test_fcnlt failure has been corrected in the latest patch. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-03-05 16:26 Message: Logged In: YES user_id=485579 Updated the patch against the latest Python 2.4a (cvs) code. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-02-05 09:00 Message: Logged In: YES user_id=485579 Yes, I'm comfortable with that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-05 07:36 Message: Logged In: YES user_id=21627 Are you willing to act as a maintainer and contact point for the Dragonfly port? ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-02-04 15:32 Message: Logged In: YES user_id=485579 Also, attached in the generated IN.py Lib/plat-dragonfly1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 From noreply at sourceforge.net Sun Jul 25 08:51:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 08:52:13 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 15:50 Message generated for change (Comment added) made by asouzis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-24 23:51 Message: Logged In: YES user_id=57486 > Why move the attributes to a class for the two tables? In general its good practice to separate the style info from the html. For this case in particular i had to do this because i'm embedding the diff tables in a generic page template that applies general style rules to tables in the page. By adding a class for those tables i was able to add a rule for it that overrode the more general table rule. > Can I get a recommended solution for the font issue? Not sure, I added this rule: .diff_table th, .diff_table td { font-size: smaller; } But its a bit problematic as Mozilla defaults to a considerably smaller monotype font size than IE so its hard to be consistent across browsers. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-24 08:29 Message: Logged In: YES user_id=995755 I will be implementing the following suggestions: Raymond 7/19 & 7/23 [all] Adam 7/17 [all] Adam 7/23 [partial, but I need feedback] - Can I get a recommended solution for the font issue? - I'll likely do the additional links column on the left - Why move the attributes to a class for the two tables? Unless the template issue (public/protected/private) is discussed further, I will assume everyone is in agreement or can live with Raymond's suggestion & clarification. I will not be implementing any changes to the API right now. I lean somewhat strong toward leaving the optional arguments as they are but this can be talked about further if anyone thinks there are strong arguments to the contrary. Thanks Raymond, Adam, Jim, and Neal for your latest comments. Unless I get further suggestions, expect the patch hopefully by the end of the weekend. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-23 21:20 Message: Logged In: YES user_id=80475 To clarify, the private variables are just a way to move the defaults out of the class definition and give the OP more control over formatting: _legend = """
Legends
Colors
 Added 
Changed
Deleted
Links
(f)irst change
(n)ext change
(t)op
""" class HtmlDiff(object): file_template = _file_template styles = _styles linenum_template = _linenum_template table_template = _table_template legend = _legend def __init__(self,prefix=['from','to'], linejunk=None, . . . ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-23 13:01 Message: Logged In: YES user_id=57486 certainly you need to be able to access the templates and modify them. And should be documented too -- one of the first things i wanted to know is how can i customize the output. But a config object seems like conceptual clutter. keyword arguments can be ignored and are just as persistent if you use ** on a dict. few more suggestions: * the default font seems too large on both ie 6 and firefox (this is with 1200 x 800 screen resolution, so it'd be even larger at a lower resolution). * maybe the links column (t, f, n) should also be on the left -- often there are long lines and you need to scroll over to access it. * add class attributes to the two tables used in the templates and move their styles to there (except i believe that IE doesn't honor cellpadding/spacing styles in css) thanks ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 09:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 09:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 06:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 04:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 06:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 12:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 02:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 02:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-14 23:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 11:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 11:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-23 23:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 07:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 21:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 06:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Sun Jul 25 12:17:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 12:17:05 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 11:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 09:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 20:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Jul 25 12:18:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 12:18:16 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Raymond Hettinger (rhettinger) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 11:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 09:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 20:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Jul 25 15:51:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 15:51:25 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-25 08:51 Message: Logged In: YES user_id=995755 Adam's suggestion seems to make alot of sense regarding moving the table attributes to a class. I will implement it in the next update. I will experiment with the font issue but will likely hold off on implementing anything. Adam -- thanks for the quick feedback. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-25 01:51 Message: Logged In: YES user_id=57486 > Why move the attributes to a class for the two tables? In general its good practice to separate the style info from the html. For this case in particular i had to do this because i'm embedding the diff tables in a generic page template that applies general style rules to tables in the page. By adding a class for those tables i was able to add a rule for it that overrode the more general table rule. > Can I get a recommended solution for the font issue? Not sure, I added this rule: .diff_table th, .diff_table td { font-size: smaller; } But its a bit problematic as Mozilla defaults to a considerably smaller monotype font size than IE so its hard to be consistent across browsers. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-24 10:29 Message: Logged In: YES user_id=995755 I will be implementing the following suggestions: Raymond 7/19 & 7/23 [all] Adam 7/17 [all] Adam 7/23 [partial, but I need feedback] - Can I get a recommended solution for the font issue? - I'll likely do the additional links column on the left - Why move the attributes to a class for the two tables? Unless the template issue (public/protected/private) is discussed further, I will assume everyone is in agreement or can live with Raymond's suggestion & clarification. I will not be implementing any changes to the API right now. I lean somewhat strong toward leaving the optional arguments as they are but this can be talked about further if anyone thinks there are strong arguments to the contrary. Thanks Raymond, Adam, Jim, and Neal for your latest comments. Unless I get further suggestions, expect the patch hopefully by the end of the weekend. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-23 23:20 Message: Logged In: YES user_id=80475 To clarify, the private variables are just a way to move the defaults out of the class definition and give the OP more control over formatting: _legend = """
Legends
Colors
 Added 
Changed
Deleted
Links
(f)irst change
(n)ext change
(t)op
""" class HtmlDiff(object): file_template = _file_template styles = _styles linenum_template = _linenum_template table_template = _table_template legend = _legend def __init__(self,prefix=['from','to'], linejunk=None, . . . ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-23 15:01 Message: Logged In: YES user_id=57486 certainly you need to be able to access the templates and modify them. And should be documented too -- one of the first things i wanted to know is how can i customize the output. But a config object seems like conceptual clutter. keyword arguments can be ignored and are just as persistent if you use ** on a dict. few more suggestions: * the default font seems too large on both ie 6 and firefox (this is with 1200 x 800 screen resolution, so it'd be even larger at a lower resolution). * maybe the links column (t, f, n) should also be on the left -- often there are long lines and you need to scroll over to access it. * add class attributes to the two tables used in the templates and move their styles to there (except i believe that IE doesn't honor cellpadding/spacing styles in css) thanks ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 11:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 10:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 10:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From h.whaasgc at grinbold.de Sun Jul 25 17:09:06 2004 From: h.whaasgc at grinbold.de (h.whaasgc@grinbold.de) Date: Sun Jul 25 17:10:50 2004 Subject: [Patches] $39757 Message-ID: Hi, We sent you an email a while ago, because you now qualify for a new mortgage. You could get $300,000 for as little as $700 a month! Bad credit is no problem, you can pull cash out or refinance. Please click on this link for free consultation: http://www.lending-home.com/ Best Regards, Jamie Higgs No thanks: http://www.lending-home.com/r1 ---- system information ---- appropriate not throughly Presentation collections danger public-i18n-ws-request@w3org problems though such fallback methods technical dates [WSUS] produces runtime application appropriately construct additional use problems fallback From noreply at sourceforge.net Sun Jul 25 19:56:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 19:56:23 2004 Subject: [Patches] [ python-Patches-997626 ] httplib.HTTPConnection.request() bug Message-ID: Patches item #997626, was opened at 2004-07-25 18:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.HTTPConnection.request() bug Initial Comment: 996159 reveals a problem with httplib.HTTPConnection.request(). The underlying problem is that, while this method checks no explicit Host: header was provided, it fails to do the same for Accept-Encoding: and Content-Length: This patch fixes that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470 From noreply at sourceforge.net Sun Jul 25 20:00:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 20:01:37 2004 Subject: [Patches] [ python-Patches-997626 ] httplib.HTTPConnection.request() bug Message-ID: Patches item #997626, was opened at 2004-07-25 18:56 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.HTTPConnection.request() bug Initial Comment: 996159 reveals a problem with httplib.HTTPConnection.request(). The underlying problem is that, while this method checks no explicit Host: header was provided, it fails to do the same for Accept-Encoding: and Content-Length: This patch fixes that. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2004-07-25 19:00 Message: Logged In: YES user_id=261020 This is important to get into 2.4, because it breaks urllib2. I haven't run the tests yet, or done any manual tests. I'll try and do that tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470 From noreply at sourceforge.net Sun Jul 25 20:02:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 20:02:51 2004 Subject: [Patches] [ python-Patches-996159 ] correct urllib2 header capitalization (fix for #994101) Message-ID: Patches item #996159, was opened at 2004-07-22 21:48 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996159&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) Summary: correct urllib2 header capitalization (fix for #994101) Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". The former form is used throughout the module as well. This is incorrect. In this patch I've removed the capitalize() calls and used the correct form throughout both the module.and the tests. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-25 19:02 Message: Logged In: YES user_id=261020 The form "User-agent" is not incorrect, merely unconventional (see RFC 2616, section 4.2). The .capitalize() calls were introduced to make headers properly case-insensitive while keeping old code working -- see patch 649742. The problem has arisen because urllib2 recently switched to using httplib.HTTPConnection (and the .request() method in particular, which sends Content-Length automatically) where previously it used httplib.HTTP (which did not send Content- Length automatically). The real problem is that httplib.HTTPConnection.request() sends some headers without checking that they aren't already in the explicitly requested headers. I have submitted patch 997626 to fix this. Thanks for reporting this, Johannes! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996159&group_id=5470 From noreply at sourceforge.net Sun Jul 25 20:03:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 20:03:43 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 22:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-25 20:03 Message: Logged In: YES user_id=21627 I dislike the idea. There are file systems which give "incorrect" link counts, most prominently Microsoft's "Server for NFS". They report two links for each directory, and subtracting. and the parent link, you find that there are never subdirectories. This causes scripts to break in mysterious way. Fortunately, GNU find has an option to suppress this optimization, but I'd like to avoid getting into the same problems with Python. Interestingly, Samba/smbfs also violates the link count rule, reporting 1 link for each directory. Subtracting 2 gives -1 subdirectories, which GNU find, by coincidence, essentially treats as "infinite number of subdirectories". It would be much better to use the "file type" feature of getdents/readdir where available, reporting an "unknown" file type where it isn't available. This allows to avoid any stat calls. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-22 00:35 Message: Logged In: YES user_id=77867 thinking about it some more, a separate function is probably a good idea. at the moment I'm calling it 'lwalk' (analogy to stat/lstat). it should be usable on systems without links too. I'll attach it in a day or two. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-21 23:37 Message: Logged In: YES user_id=77867 the chdir() optimization seems to be mostly insignificant on modern systems (I'm doing timings on linux 2.6). perl will do chdir too, and it's only slightly faster than python if nlinks gets used, and the amount of system time used is pretty indistinguishable among all the versions. I suspect ram is cheap enough that large dir->inode caches are easy and fast. the remaining difference in speed between GNU find and a perl or python version is in user time, and I think most of that can be attributed to interpreter overhead. crossing a function call boundary 100,000 times is hard to make fast in any interpreted language. the nlink optimization is significant, I think that's worth doing, but I don't think any other optimization is. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-21 17:52 Message: Logged In: YES user_id=2772 GNU find also uses os.chdir() to descend into the directory hierarchy, which means that all its "stat" calls use filenames within the current directory. Clearly, python's os.walk can't do this, because the working directory is shared among threads. Disaster would result. But, anyway, this is another reason that os.walk is slower than find. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 14:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Sun Jul 25 20:09:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 20:09:39 2004 Subject: [Patches] [ python-Patches-997626 ] httplib.HTTPConnection.request() bug Message-ID: Patches item #997626, was opened at 2004-07-25 18:56 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.HTTPConnection.request() bug Initial Comment: 996159 reveals a problem with httplib.HTTPConnection.request(). The underlying problem is that, while this method checks no explicit Host: header was provided, it fails to do the same for Accept-Encoding: and Content-Length: This patch fixes that. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2004-07-25 19:09 Message: Logged In: YES user_id=261020 Of course, urllib2 should also be fixed not to add Host and Content-Length headers (httplib makes a better job of it), but that's a separate bug which I'll file separately. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-25 19:00 Message: Logged In: YES user_id=261020 This is important to get into 2.4, because it breaks urllib2. I haven't run the tests yet, or done any manual tests. I'll try and do that tomorrow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470 From noreply at sourceforge.net Sun Jul 25 20:45:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 20:45:37 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 20:04 Message generated for change (Comment added) made by felixlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- >Comment By: Felix Lee (felixlee) Date: 2004-07-25 18:45 Message: Logged In: YES user_id=77867 my heuristic works correctly for those cases you describe. it never trusts st_nlink < 2, and before it trusts st_nlink == 2, it checks one directory to see if st_nlink correctly describes the number of subdirs. the version in walk4.py will get confused if it crosses a mount point from a filesystem where st_nlink is accurate to a filesystem where it isn't. that isn't hard to deal with either, but the usual way to check for crossing a filesystem boundary is to look at st_dev, and I don't have any idea how reliable that is for non-unix systems. it seems plausible to me that any system where st_dev doesn't work will also have an st_nlink that doesn't work, which will be detected properly, so that might not be a problem. this makes it more system-dependent than I like. it might be better to call it something like os.posix.lwalk. the filetype returned by getdirentries isn't exposed by any python functions. it would require adding C code, which may be worth doing. it seems to me that's a separate issue. none of the OSes I use will supply that information, so I'm probably not the right person to look at this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-25 18:03 Message: Logged In: YES user_id=21627 I dislike the idea. There are file systems which give "incorrect" link counts, most prominently Microsoft's "Server for NFS". They report two links for each directory, and subtracting. and the parent link, you find that there are never subdirectories. This causes scripts to break in mysterious way. Fortunately, GNU find has an option to suppress this optimization, but I'd like to avoid getting into the same problems with Python. Interestingly, Samba/smbfs also violates the link count rule, reporting 1 link for each directory. Subtracting 2 gives -1 subdirectories, which GNU find, by coincidence, essentially treats as "infinite number of subdirectories". It would be much better to use the "file type" feature of getdents/readdir where available, reporting an "unknown" file type where it isn't available. This allows to avoid any stat calls. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-21 22:35 Message: Logged In: YES user_id=77867 thinking about it some more, a separate function is probably a good idea. at the moment I'm calling it 'lwalk' (analogy to stat/lstat). it should be usable on systems without links too. I'll attach it in a day or two. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-21 21:37 Message: Logged In: YES user_id=77867 the chdir() optimization seems to be mostly insignificant on modern systems (I'm doing timings on linux 2.6). perl will do chdir too, and it's only slightly faster than python if nlinks gets used, and the amount of system time used is pretty indistinguishable among all the versions. I suspect ram is cheap enough that large dir->inode caches are easy and fast. the remaining difference in speed between GNU find and a perl or python version is in user time, and I think most of that can be attributed to interpreter overhead. crossing a function call boundary 100,000 times is hard to make fast in any interpreted language. the nlink optimization is significant, I think that's worth doing, but I don't think any other optimization is. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-21 15:52 Message: Logged In: YES user_id=2772 GNU find also uses os.chdir() to descend into the directory hierarchy, which means that all its "stat" calls use filenames within the current directory. Clearly, python's os.walk can't do this, because the working directory is shared among threads. Disaster would result. But, anyway, this is another reason that os.walk is slower than find. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 12:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Sun Jul 25 21:34:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 21:34:57 2004 Subject: [Patches] [ python-Patches-997668 ] crypt module documentation extended Message-ID: Patches item #997668, was opened at 2004-07-25 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=997668&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fernando Altomare Serboncini (fserb) Assigned to: Nobody/Anonymous (nobody) Summary: crypt module documentation extended Initial Comment: I thought there was some information missing on the crypt module documentation. I've changed two things basically. First, I made it clear that every extension (or general behavior) of the crypt(3) implementation on the running system will also be valid on the crypt module. Second, since some extensions (as the GNU extension on Linux) allows different values on the salt parameter, the whole crypted password should be used as salt when checking for a password. With this, I've corrected the example code to use the full cryptedpasswd instead of cryptedpasswd[:2] I would've changed the whole example to a simpler one. But left it to another patch. Since this is my first python patch, hope I've not made anything stupid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997668&group_id=5470 From noreply at sourceforge.net Sun Jul 25 22:47:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jul 25 22:47:25 2004 Subject: [Patches] [ python-Patches-994057 ] faster os.walk Message-ID: Patches item #994057, was opened at 2004-07-19 22:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: faster os.walk Initial Comment: On Unix-like filesystems, you can get a substantial speedup for directory traversal if you look at a directory's st_nlink count to find out how many subdirectories are in a directory. Once you've seen that many subdirs, you know the rest of the entries have to be nondirectory files, so you don't have to stat() them. this is often a big win because most people put most of their files in leaf directories. For my home directory, using the link count reduces it from 100,000 stat calls to 20,000 stat calls, which cuts execution time about 70% when all the filesystem data is already in RAM. I think the speedup is more when the data has to be read from disk, but I don't have an easy way of measuring that. the GNU "find" program does this optimization. so does Perl's File::Find. the attached file is a proof of concept implementation. if this seems like a reasonable thing to do, I can rewrite it as a patch with appropriate documentation. there are a few problems with it. 1. it needs to be tested on OSes I don't have. this uses a simple heuristic to decide whether the link count can be used or not, so it shouldn't be necessary to add OS-specific tests, but I don't know how perverse other OSes are. 2. to do the nlink optimization, links to directories have to be considered files rather than directories. this is different from existing behavior, where links to directories are returned as directories but never entered. I don't think the existing behavior is useful, but it seems like a bad idea to change it, since there may be things that depend on it. the simple way of handling this is to make use_nlink=0 the default, so the speedup and the changed behavior happen only when someone specifically requests it. I don't really like this, because I think it's rare that use_nlink=0 is desirable if the heuristic is reliable. another way of handling this is to make a new function instead of modifying os.walk. a new function could also have the option of following links without getting stuck in loops. 3. the faster walk is still noticeably slower than list(popen("find")). (Perl has this problem too.) there isn't really much to be done about that, it's mostly just interpreter overhead. this speed difference probably isn't significant in most cases, and cross-platform portability is a good reason for using walk instead of popen('find'). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-25 22:47 Message: Logged In: YES user_id=21627 Based on the possibility of the heuristics still being wrong, I'm rejecting this patch. As it is pure Python, it should be easy enough to incorporate into application that really need the extra performance, and know for sure that the heuristics is right in their case. So you might consider publishing it in the Python Cookbook, or releasing it as a separate module somewhere on the net. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-25 20:45 Message: Logged In: YES user_id=77867 my heuristic works correctly for those cases you describe. it never trusts st_nlink < 2, and before it trusts st_nlink == 2, it checks one directory to see if st_nlink correctly describes the number of subdirs. the version in walk4.py will get confused if it crosses a mount point from a filesystem where st_nlink is accurate to a filesystem where it isn't. that isn't hard to deal with either, but the usual way to check for crossing a filesystem boundary is to look at st_dev, and I don't have any idea how reliable that is for non-unix systems. it seems plausible to me that any system where st_dev doesn't work will also have an st_nlink that doesn't work, which will be detected properly, so that might not be a problem. this makes it more system-dependent than I like. it might be better to call it something like os.posix.lwalk. the filetype returned by getdirentries isn't exposed by any python functions. it would require adding C code, which may be worth doing. it seems to me that's a separate issue. none of the OSes I use will supply that information, so I'm probably not the right person to look at this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-25 20:03 Message: Logged In: YES user_id=21627 I dislike the idea. There are file systems which give "incorrect" link counts, most prominently Microsoft's "Server for NFS". They report two links for each directory, and subtracting. and the parent link, you find that there are never subdirectories. This causes scripts to break in mysterious way. Fortunately, GNU find has an option to suppress this optimization, but I'd like to avoid getting into the same problems with Python. Interestingly, Samba/smbfs also violates the link count rule, reporting 1 link for each directory. Subtracting 2 gives -1 subdirectories, which GNU find, by coincidence, essentially treats as "infinite number of subdirectories". It would be much better to use the "file type" feature of getdents/readdir where available, reporting an "unknown" file type where it isn't available. This allows to avoid any stat calls. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-22 00:35 Message: Logged In: YES user_id=77867 thinking about it some more, a separate function is probably a good idea. at the moment I'm calling it 'lwalk' (analogy to stat/lstat). it should be usable on systems without links too. I'll attach it in a day or two. ---------------------------------------------------------------------- Comment By: Felix Lee (felixlee) Date: 2004-07-21 23:37 Message: Logged In: YES user_id=77867 the chdir() optimization seems to be mostly insignificant on modern systems (I'm doing timings on linux 2.6). perl will do chdir too, and it's only slightly faster than python if nlinks gets used, and the amount of system time used is pretty indistinguishable among all the versions. I suspect ram is cheap enough that large dir->inode caches are easy and fast. the remaining difference in speed between GNU find and a perl or python version is in user time, and I think most of that can be attributed to interpreter overhead. crossing a function call boundary 100,000 times is hard to make fast in any interpreted language. the nlink optimization is significant, I think that's worth doing, but I don't think any other optimization is. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-07-21 17:52 Message: Logged In: YES user_id=2772 GNU find also uses os.chdir() to descend into the directory hierarchy, which means that all its "stat" calls use filenames within the current directory. Clearly, python's os.walk can't do this, because the working directory is shared among threads. Disaster would result. But, anyway, this is another reason that os.walk is slower than find. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 14:05 Message: Logged In: YES user_id=99874 Okay, I like the idea (haven't read the patch yet). Your problem 1 will just take time, and problem 3 isn't really a problem. But problem 2 is a real issue. I think having a new function is not worth it (or rather, I'd say, it's worth having, just not in the standard library). I think having a hardly-ever-used option "use_nlinik" is a non-starter. So despite liking the idea, I'm stimied^H^H stymied^H^H stimyed^H^H confounded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994057&group_id=5470 From noreply at sourceforge.net Mon Jul 26 05:17:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 05:17:41 2004 Subject: [Patches] [ python-Patches-605370 ] nntplib: group descriptions and RFC2980 Message-ID: Patches item #605370, was opened at 2002-09-06 04:37 Message generated for change (Comment added) made by jae You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J?rgen A. Erhard (jae) Assigned to: Nobody/Anonymous (nobody) Summary: nntplib: group descriptions and RFC2980 Initial Comment: nntplib's NNTP.xgtitle() is deprecated by RFC2980. And some servers (like leafnode) don't even know XGTITLE. This adds two methods to NNTP, description and descriptions. NNTP.description just gets the description of one group (and doesn't return the server status code). NNTP.descriptions does the same as xgtitle does now, but in a more general, and RFC2980 compliant way. It tries the RFC2980 way (LIST NEWSGROUPS) and if this fails, falls back to XGTITLE. This patch also adds an new optional "groups" argument to the NNTP.list. I thought it fitting to mirror the "LIST/LIST NEWSGROUPS" in the method. Feel free to kill this part, I'm not really attached to it. I do prefer description/descriptions, as they make the code more self-documenting. (If you insist: I'm on Debian GNU/Linux "sid", python2.2.1... but the patch should apply cleanly against CVS, doerwalter's checkin shouldn't conflict) ---------------------------------------------------------------------- >Comment By: J?rgen A. Erhard (jae) Date: 2004-07-26 05:17 Message: Logged In: YES user_id=10380 Killed the change to the "list" method. Removed old patch, added new patch, and a doc patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-13 15:08 Message: Logged In: YES user_id=21627 Can you please provide documentation patches (for libnntplib.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 From noreply at sourceforge.net Mon Jul 26 05:21:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 05:21:14 2004 Subject: [Patches] [ python-Patches-605370 ] nntplib: group descriptions and RFC2980 Message-ID: Patches item #605370, was opened at 2002-09-06 04:37 Message generated for change (Settings changed) made by jae You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J?rgen A. Erhard (jae) Assigned to: Nobody/Anonymous (nobody) Summary: nntplib: group descriptions and RFC2980 Initial Comment: nntplib's NNTP.xgtitle() is deprecated by RFC2980. And some servers (like leafnode) don't even know XGTITLE. This adds two methods to NNTP, description and descriptions. NNTP.description just gets the description of one group (and doesn't return the server status code). NNTP.descriptions does the same as xgtitle does now, but in a more general, and RFC2980 compliant way. It tries the RFC2980 way (LIST NEWSGROUPS) and if this fails, falls back to XGTITLE. This patch also adds an new optional "groups" argument to the NNTP.list. I thought it fitting to mirror the "LIST/LIST NEWSGROUPS" in the method. Feel free to kill this part, I'm not really attached to it. I do prefer description/descriptions, as they make the code more self-documenting. (If you insist: I'm on Debian GNU/Linux "sid", python2.2.1... but the patch should apply cleanly against CVS, doerwalter's checkin shouldn't conflict) ---------------------------------------------------------------------- Comment By: J?rgen A. Erhard (jae) Date: 2004-07-26 05:17 Message: Logged In: YES user_id=10380 Killed the change to the "list" method. Removed old patch, added new patch, and a doc patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-13 15:08 Message: Logged In: YES user_id=21627 Can you please provide documentation patches (for libnntplib.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 From noreply at sourceforge.net Mon Jul 26 07:44:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 07:44:38 2004 Subject: [Patches] [ python-Patches-605370 ] nntplib: group descriptions and RFC2980 Message-ID: Patches item #605370, was opened at 2002-09-06 04:37 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: J?rgen A. Erhard (jae) >Assigned to: Martin v. L?wis (loewis) Summary: nntplib: group descriptions and RFC2980 Initial Comment: nntplib's NNTP.xgtitle() is deprecated by RFC2980. And some servers (like leafnode) don't even know XGTITLE. This adds two methods to NNTP, description and descriptions. NNTP.description just gets the description of one group (and doesn't return the server status code). NNTP.descriptions does the same as xgtitle does now, but in a more general, and RFC2980 compliant way. It tries the RFC2980 way (LIST NEWSGROUPS) and if this fails, falls back to XGTITLE. This patch also adds an new optional "groups" argument to the NNTP.list. I thought it fitting to mirror the "LIST/LIST NEWSGROUPS" in the method. Feel free to kill this part, I'm not really attached to it. I do prefer description/descriptions, as they make the code more self-documenting. (If you insist: I'm on Debian GNU/Linux "sid", python2.2.1... but the patch should apply cleanly against CVS, doerwalter's checkin shouldn't conflict) ---------------------------------------------------------------------- Comment By: J?rgen A. Erhard (jae) Date: 2004-07-26 05:17 Message: Logged In: YES user_id=10380 Killed the change to the "list" method. Removed old patch, added new patch, and a doc patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-13 15:08 Message: Logged In: YES user_id=21627 Can you please provide documentation patches (for libnntplib.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 From noreply at sourceforge.net Mon Jul 26 08:34:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 08:34:28 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-07-26 01:34 Message: Logged In: YES user_id=995755 Updated the patch as follows: 1) handles no differences now in both full and context mode (Adam discovered that it crashed when no differences in context mode). 2) handles empty string lists (I'm pretty sure it would have crashed had someone tried it). 3) "links" column in the middle now appears on the left as well. 4) Moved prefix argument from constructor to make_file and make_table methods. Also made it work by default so that if you are generating multiple tables and putting them on the same HTML page there are no anchor name conflicts. 5) mdiff() function now is protected: _mdiff() so we are at liberty to change the interface in the future 6) templates moved to protected global variables (still public members of the class) so that the indenting could be improved. 7) Improved the indenting in other areas so that the HTML is now much more readable. 8) Inlined the special character escaping so that the xml.sax library function is not used (this seems to have improved the performance quite a bit). 9) Moved as many attributes as possible to a style sheet class. Adam, please review this incase I missed some. 10) Expanded test suite to cover the above changes and made it easier to baseline. 11) Updated documentation to reflect above changes. NOTES N1) Raymond, you had mentioned this crashes when the newlines are stripped. I modified the test to include stripping and not and have found both to work without having to fix anything. Can you duplicate what you saw and give me more info? N2) I've noticed the HTML does not render tabs very well (at all). Is this OK or does anyone have any good ideas? N3) I've attached the patch (you will also need the new file test_difflib_expect.html). I've zipped the patched code as well as example side by side differences of the patch. Diffs ending with _UPDATE.html show differences between the patched code and the last version of the patched code (what I've done since my last posting). Diffs ending with _PATCH.html show differences between the patched code and what I obtained from CVS a couple weeks back: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-25 08:51 Message: Logged In: YES user_id=995755 Adam's suggestion seems to make alot of sense regarding moving the table attributes to a class. I will implement it in the next update. I will experiment with the font issue but will likely hold off on implementing anything. Adam -- thanks for the quick feedback. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-25 01:51 Message: Logged In: YES user_id=57486 > Why move the attributes to a class for the two tables? In general its good practice to separate the style info from the html. For this case in particular i had to do this because i'm embedding the diff tables in a generic page template that applies general style rules to tables in the page. By adding a class for those tables i was able to add a rule for it that overrode the more general table rule. > Can I get a recommended solution for the font issue? Not sure, I added this rule: .diff_table th, .diff_table td { font-size: smaller; } But its a bit problematic as Mozilla defaults to a considerably smaller monotype font size than IE so its hard to be consistent across browsers. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-24 10:29 Message: Logged In: YES user_id=995755 I will be implementing the following suggestions: Raymond 7/19 & 7/23 [all] Adam 7/17 [all] Adam 7/23 [partial, but I need feedback] - Can I get a recommended solution for the font issue? - I'll likely do the additional links column on the left - Why move the attributes to a class for the two tables? Unless the template issue (public/protected/private) is discussed further, I will assume everyone is in agreement or can live with Raymond's suggestion & clarification. I will not be implementing any changes to the API right now. I lean somewhat strong toward leaving the optional arguments as they are but this can be talked about further if anyone thinks there are strong arguments to the contrary. Thanks Raymond, Adam, Jim, and Neal for your latest comments. Unless I get further suggestions, expect the patch hopefully by the end of the weekend. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-23 23:20 Message: Logged In: YES user_id=80475 To clarify, the private variables are just a way to move the defaults out of the class definition and give the OP more control over formatting: _legend = """
Legends
Colors
 Added 
Changed
Deleted
Links
(f)irst change
(n)ext change
(t)op
""" class HtmlDiff(object): file_template = _file_template styles = _styles linenum_template = _linenum_template table_template = _table_template legend = _legend def __init__(self,prefix=['from','to'], linejunk=None, . . . ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-23 15:01 Message: Logged In: YES user_id=57486 certainly you need to be able to access the templates and modify them. And should be documented too -- one of the first things i wanted to know is how can i customize the output. But a config object seems like conceptual clutter. keyword arguments can be ignored and are just as persistent if you use ** on a dict. few more suggestions: * the default font seems too large on both ie 6 and firefox (this is with 1200 x 800 screen resolution, so it'd be even larger at a lower resolution). * maybe the links column (t, f, n) should also be on the left -- often there are long lines and you need to scroll over to access it. * add class attributes to the two tables used in the templates and move their styles to there (except i believe that IE doesn't honor cellpadding/spacing styles in css) thanks ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 11:31 Message: Logged In: YES user_id=764593 Actually, I'm not convinced that the templates should be private, though I can certainly see protected. (double- underscore private is mangled; single-underscore protected will be left out of some imports and doco, but acts like a regular variable if people choose to use it anyway.) I'm still thinking about nnorwitz's suggestion; the config option could be ignored by most people ("use the defaults") but would hold persistent state for people with explicit preferences (since they'll probably want to make the same changes to all compares). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-23 11:10 Message: Logged In: YES user_id=33168 I have not reviewed the code yet, so this is just a general comment. I don't know if it is applicable. You could create a configuration class that has attributes. A user would only need to assign to the params that they want to update. If you change the names you could add properties to deal with backwards compatibility. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 10:48 Message: Logged In: YES user_id=995755 I agree the API for make_file() and make_table() has alot of optional parameters that can look daunting. The alternative of providing accessor methods is less appealing to me. It sounds like Jim & I are in agreement on this. As far as the compromise of making the templates private members, I am assuming Jim is in favor of it. I'm in favor of them being members, it doesn't matter to me if they are private. I'll wait until Raymond weighs in on this one before I move on it. Jim -- Thanks for your input. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 10:17 Message: Logged In: YES user_id=764593 For a context or unified diff, you don't really need to parametrize it very much. Having a much larger API for side- by-side puts things out of balance, which can make side-by- side look either more difficult or preferred. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 08:57 Message: Logged In: YES user_id=995755 Maybe a good compromise would be to leave them members of the class but name them to imply they are private (add a leading underscore). That way if someone wants to create their own subclass they can at their own risk. They can always write a little extra logic to insure the interface didn't change and raise a custom exception explaining what happened and what they need to look at. I didn't read (2) in Raymond's comments. Could you expand on those concerns? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-23 08:24 Message: Logged In: YES user_id=764593 I agree that users should be able to override the template. I think Raymond was concerned about (1) backwards compatibility if you want to change the interface. For instance, you might later decide that there should be separate templates for header/footer/match section/ changed line/added line/deleted line. (2) matching the other diff options, so this doesn't look far more complicated. Unfortunately, at the moment I don't see a good way to solve those; using a private member and access functions wouldn't really simplify things much. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-23 06:53 Message: Logged In: YES user_id=995755 I intend on implementing all the suggestions from the last two comment submissions when I hear back from Raymond Hettinger. I'm questioning making the templates private global variables. I intentionally made them members of a class so that they could be overridden when the class is subclassed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 08:12 Message: Logged In: YES user_id=80475 Unfortunately, I do not have time to give this more review. Several thoughts: - consider making mdiff as private. that will leave its API flexible to accomodate future changes - move the templates to private global variables and work to improve their indentation so that the html is readable - inline the code for _escape from sax. the three replaces are not worth the interdependency - the methods work fine with properly formatted input but crash badly when the newlines have been stripped. So, either make the code more flexible or add error handling. - overall, nice job. ---------------------------------------------------------------------- Comment By: Adam Souzis (asouzis) Date: 2004-07-17 14:12 Message: Logged In: YES user_id=57486 The diffs look cool but if the to and from lines are identical an exception is thrown: File "", line 23, in makeDiff File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file summary=summary)) File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table if not diff_flags[0]: IndexError: list index out of range (This is on python 2.3.3 -- I renamed your difflib.py to htmldiff.py and put it in site-packages) Perhaps you should add the case of two identical files to test_difflib.py. thanks ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:16 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-16 04:13 Message: Logged In: YES user_id=995755 Since I have not gotten any feedback on the user interface I took the liberty to tweek it the best I thought how. Since I consider this new functionality very solid I went ahead and created changes to the documentation and test suite. Per Martin v. L?wis (loewis) instructions I generated a patch which hopefully meets his needs. My CVS access is limited to the web interface and thus the patch is based on the latest checked in as of today: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 Note, I am not very familiar with .tex but it seemed straight forward. I editted the file by hand and it should be very close to what I intended. Unfortunately I am not set up to convert the .tex to HTML. I may try that next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 01:30 Message: Logged In: YES user_id=21627 The pack lacks changes to the documentation (libdifflib.tex) and changes to the test suite. Please always submit patches as single unified or context diffs, rather than zip files of the revised files. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-02 13:17 Message: Logged In: YES user_id=995755 With the updated patch code I just posted, both full and contextual differences pass the validator.w3.org check (XHTML 1.0 Transitional). Also the extra carriage returns put in by DOS were removed from the difflib.py patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-25 13:01 Message: Logged In: YES user_id=89016 Submitting difflib_context.html to validator.w3.org gives 2333 errors. The character encoding is missing and there's no DOCTYPE declaration. The rest of the errors seem to be mostly related to the nowrap attribute (which must be written as nowrap="nowrap", as this is the only allowed value). Furthermore the patch contains a mix of CR and CRLF terminated lines. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-06-24 01:23 Message: Logged In: YES user_id=995755 I just attached an updated patch. I based the patch on diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I saw today on viewCVS. The following enhancements were made: 1) user interface greatly simplified for generating HTML (see diff.py for example) 2) generated HTML now 4.01 Transitional compliant (so says HTML Tidy) 3) HTML color scheme for differences now matches that used by viewCVS. 4) differences table now has a row for each line making the HTML less susceptible to browser quirks. 5) took care of all issues to date enumerated here in this patch. It would be great if I could get some help on: A) getting some JavaScript? written to be able to select and cut text from a single column (right now text is selected from the whole row including both "from" and "to" text and line numbers. B) solving the line width issue. Currently the "from" / "to" column is as wide as the widest line. Any ideas on wrapping or scrolling? As of now the only feature I may want to add in the near future is optional tab expansion. Thanks to those that have commented here and emailed me with suggestions and advice! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-11 09:35 Message: Logged In: YES user_id=764593 Thank you; I have often wished for side-by-side, but not quite badly enough to write it. That said, I would recommend some tweaks to the formatting. "font" is deprecated; "span" would be better. On my display, the "next" lines don't always seem to be counted (except the first one), so that the anchors column is not lined up with the others. (This would also be fixed by the separate rows suggestion.) Ideally, the line numbers would be in a separate column from the code, to make cut'n'paste easier. (Then you could replace font.num (or span.num) with td.linenum.) Ideally, each change group should be a separate row in the table. (I realize that this probably means a two-layer iterator, so that the line breaks and blank lines can be inserted correctly in the code columns.) ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-28 23:30 Message: Logged In: YES user_id=995755 Also, I will need to submit the fix for making it behave nice when there are no differences!! ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-04-09 08:30 Message: Logged In: YES user_id=995755 In the time since submission I've found that the interface to the chgFmt and lineFmt functions (arguments of mdiff) should include both the line number and an indication of side (from/to). The use for it I've found is for dropping anchors into the generated markup that it can be hyperlinked from elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:07:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:07:17 2004 Subject: [Patches] [ python-Patches-997668 ] crypt module documentation extended Message-ID: Patches item #997668, was opened at 2004-07-25 21:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997668&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Fernando Altomare Serboncini (fserb) Assigned to: Nobody/Anonymous (nobody) Summary: crypt module documentation extended Initial Comment: I thought there was some information missing on the crypt module documentation. I've changed two things basically. First, I made it clear that every extension (or general behavior) of the crypt(3) implementation on the running system will also be valid on the crypt module. Second, since some extensions (as the GNU extension on Linux) allows different values on the salt parameter, the whole crypted password should be used as salt when checking for a password. With this, I've corrected the example code to use the full cryptedpasswd instead of cryptedpasswd[:2] I would've changed the whole example to a simpler one. But left it to another patch. Since this is my first python patch, hope I've not made anything stupid. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:07 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as libcrypt.tex 1.17 and 1.16.36.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997668&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:10:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:10:23 2004 Subject: [Patches] [ python-Patches-995782 ] Skipped test expectations for freebsd5 Message-ID: Patches item #995782, was opened at 2004-07-22 10:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995782&group_id=5470 Category: Tests Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Skipped test expectations for freebsd5 Initial Comment: Add list of tests that we expect to skip on freebsd5. Looking over the tests for freebsd4, it seems that they would apply on any version of FreeBSD, so the list is not duplicated explicitly. If in the future we find that the list usually doesn't differ between different versions of the same system, it might make sense to support patterns like 'freebsd*' instead of listing each version explicitly. FWIW, all tests pass on a July 3rd -CURRENT ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:10 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as regrtest.py 1.156 and 1.145.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995782&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:16:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:16:43 2004 Subject: [Patches] [ python-Patches-995766 ] Keyword argument support in cPickle Message-ID: Patches item #995766, was opened at 2004-07-22 10:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword argument support in cPickle Initial Comment: Add keyword argument support to the "dump", "dumps", and "Pickler" callables in the cPickle module. This provides better API compatibility with the pure-Python pickle module. There are several other differences, but this one is probably the most user-visible and likely to be noticed. And it's easy to fix! The callables chosen are those that take multiple arguments. This patch addresses bug #888594 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:16 Message: Logged In: YES user_id=21627 The patch is incorrect: the first argument is called object. Please also double-check consistency with the documentation. I'm going to apply the revised version for 2.4 only, as this is a subtle behaviour change. If you think it should be backported to 2.3 as well, please indicate so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:19:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:19:06 2004 Subject: [Patches] [ python-Patches-994595 ] HTTP basic authentication problem Message-ID: Patches item #994595, was opened at 2004-07-20 17:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Catalin Marinas (c_marinas) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP basic authentication problem Initial Comment: The regular expression matching in the AbstractBasicAuthHandler.http_error_auth_reqed() function in the urllib2 module doesn't work if the authorization string returned by the server contains one or more words in front of 'Basic realm="..."'. The patch changes the rx.match() to rx.search(). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:19 Message: Logged In: YES user_id=21627 Can you please give an example of a header that is not correctly detected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:31:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:31:22 2004 Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call Message-ID: Patches item #977553, was opened at 2004-06-22 17:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up EnumKey call Initial Comment: This patch removes the RegQueryInfoKey call and replaces it with a call to EnumKeyEx. This greatly speeds up this call. The script below times python 2.3 5531 89.7130000591 python 2.4 +patch 5531 0.0469999313354 start = time.time() i = 0 try: while 1: _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i) i += 1 except WindowsError: pass print i, time.time() - start ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:31 Message: Logged In: YES user_id=21627 Also, please follow the Python style guide for C code, PEP 7. In particular: - use tabs for indentation, with a tab being worth 8 spaces - omit spaces after opening and before closing parens - put the opening brace of a code block on the same line as the keyword ---------------------------------------------------------------------- Comment By: Garth Bushell (garth42) Date: 2004-07-14 18:12 Message: Logged In: YES user_id=45280 mmangino: Yes you're correct it should be 256 in both cases. Doh! I'll attach a new patch in a while. but It's easy to mmodify the patch and up the linit to 256 theller: The advantage of the latter is it returns the Length of the string returned so we can pass it straight back to the string creation funtion in python without a strlen. also the SDK says this.... Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should use the RegEnumKeyEx function. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-14 17:54 Message: Logged In: YES user_id=11105 I'm curious: Why did you replace RegEnumKey with RegEnumKeyEx? Are there any advantages of the latter? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2004-07-14 16:12 Message: Logged In: YES user_id=74879 This looks good to me, but I think the buffer size is off by one. I read the SDK to say tha they key can be 255 characters. That means you need to allocate 256 characters to allow for the null terminator. Could you create a test case for a max length registry key? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:41:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:41:41 2004 Subject: [Patches] [ python-Patches-605370 ] nntplib: group descriptions and RFC2980 Message-ID: Patches item #605370, was opened at 2002-09-06 04:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: J?rgen A. Erhard (jae) Assigned to: Martin v. L?wis (loewis) Summary: nntplib: group descriptions and RFC2980 Initial Comment: nntplib's NNTP.xgtitle() is deprecated by RFC2980. And some servers (like leafnode) don't even know XGTITLE. This adds two methods to NNTP, description and descriptions. NNTP.description just gets the description of one group (and doesn't return the server status code). NNTP.descriptions does the same as xgtitle does now, but in a more general, and RFC2980 compliant way. It tries the RFC2980 way (LIST NEWSGROUPS) and if this fails, falls back to XGTITLE. This patch also adds an new optional "groups" argument to the NNTP.list. I thought it fitting to mirror the "LIST/LIST NEWSGROUPS" in the method. Feel free to kill this part, I'm not really attached to it. I do prefer description/descriptions, as they make the code more self-documenting. (If you insist: I'm on Debian GNU/Linux "sid", python2.2.1... but the patch should apply cleanly against CVS, doerwalter's checkin shouldn't conflict) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:41 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libnntplib.tex 1.30 nntplib.py 1.38 ACKS 1.273 NEWS 1.1054 ---------------------------------------------------------------------- Comment By: J?rgen A. Erhard (jae) Date: 2004-07-26 05:17 Message: Logged In: YES user_id=10380 Killed the change to the "list" method. Removed old patch, added new patch, and a doc patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-13 15:08 Message: Logged In: YES user_id=21627 Can you please provide documentation patches (for libnntplib.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:46:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:46:41 2004 Subject: [Patches] [ python-Patches-962487 ] locale.getdefaultlocale fails with empty env. variable Message-ID: Patches item #962487, was opened at 2004-05-29 00:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962487&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultlocale fails with empty env. variable Initial Comment: [forwarded from http://bugs.debian.org/249816] When getdefaultlocale receives an empty string in one of the LANGUAGE, LC_ALL, LC_CTYPE or LANG variables it passes it to _parse_localename function causing a ValueError. It can be easily fixed by checking the truth value of the os.environ.get instead of checking if it's None. The added patch fixes the problem. 342c342 < if localename is not None: --- > if localename: ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:46 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as locale.py 1.28 and 1.25.10.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=962487&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:47:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:47:42 2004 Subject: [Patches] [ python-Patches-823072 ] add option to NOT use ~/.netrc in nntplib.NNTP() Message-ID: Patches item #823072, was opened at 2003-10-14 00:09 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823072&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. L?wis (loewis) Summary: add option to NOT use ~/.netrc in nntplib.NNTP() Initial Comment: [forwarded from http://bugs.debian.org/215446] It should be possible to circumvent the use of ~/.netrc when calling the nntplib.NNTP() method by adding an addtional parameter. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-11-16 15:23 Message: Logged In: YES user_id=60903 add doc patch ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2003-10-14 02:29 Message: Logged In: YES user_id=162094 No documentation (http://www.python.org/doc/current/lib/module- nntplib.html) patch provided. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823072&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:58:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:58:36 2004 Subject: [Patches] [ python-Patches-997768 ] LC_CTYPE locale and strings Message-ID: Patches item #997768, was opened at 2004-07-26 03:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997768&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pekka Pessi (ppessi) Assigned to: Nobody/Anonymous (nobody) Summary: LC_CTYPE locale and strings Initial Comment: It would be nice to get access to complete locale-specific ctype information: iscntrl() isgraph() isprint() ispunct() Also, the string.uppercase and string.lowercase depend on LC_CTYPE locale. The string module has two other members that could depend on LC_CTYPE, string.punctuation and string.printable. The current docs (in http://www.python.org/doc/2.3.4/lib/module-string.html) on string.printable is misleading, as string.printable is not changed after LC_CTYPE locale changes, and it is always printable = digits + ascii_letters + punctuation + whitespace My approach is to create string.printable and string.punctuation based on locale information, just like string.uppercase and string.lowercase is done, and add string.ascii_punctuation and string.ascii_printable for the C locale values. Patch containing proposed changes in stringobject, string and _locale modules attached. No tests nor changes to the docs, sorry. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:58 Message: Logged In: YES user_id=21627 Why do you need these functions? It is convention that the Unicode type provides the same or more methods, can you provide a patch that has a meaningful definition for these methods for Unicode strings? Reclassifying issue as a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997768&group_id=5470 From noreply at sourceforge.net Mon Jul 26 14:59:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 14:59:13 2004 Subject: [Patches] [ python-Patches-997726 ] dircache fix; raise like os.listdir, plus optimization Message-ID: Patches item #997726, was opened at 2004-07-26 00:21 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997726&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carl Henrik Holth Lunde (chlunde) Assigned to: Nobody/Anonymous (nobody) Summary: dircache fix; raise like os.listdir, plus optimization Initial Comment: I think it would be better if dircache.listdir acts like os.listdir on missing directories; raise os.error Additionally, I rewrote the logic so it's about 15% faster. If you remove the outer try-except-block which purges the cache for a folder on a miss it's 30% faster. This makes if five times as fast as os.listdir (with my program). Not sure if anybody cares about the speed, the thing I was surprised about was that dircache wasn't a drop-in replacement for listdir. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997726&group_id=5470 From noreply at sourceforge.net Mon Jul 26 15:18:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 15:18:26 2004 Subject: [Patches] [ python-Patches-995766 ] Keyword argument support in cPickle Message-ID: Patches item #995766, was opened at 2004-07-22 08:25 Message generated for change (Comment added) made by ddorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword argument support in cPickle Initial Comment: Add keyword argument support to the "dump", "dumps", and "Pickler" callables in the cPickle module. This provides better API compatibility with the pure-Python pickle module. There are several other differences, but this one is probably the most user-visible and likely to be noticed. And it's easy to fix! The callables chosen are those that take multiple arguments. This patch addresses bug #888594 ---------------------------------------------------------------------- >Comment By: Dima Dorfman (ddorfman) Date: 2004-07-26 13:18 Message: Logged In: YES user_id=908995 The patch does what it claims to do--be more compatible with the pure-Python pickle module, which uses "obj" as the first argument. I noticed that when I made the change and should have mentioned it in the initial comment. I intend to submit a patch to the documentation to change the first argument to "obj". Although I think "object" is better, someone might be relying on the pure-Python using obj even though the documentation is wrong about that. I see no reason to backport this to 2.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 12:16 Message: Logged In: YES user_id=21627 The patch is incorrect: the first argument is called object. Please also double-check consistency with the documentation. I'm going to apply the revised version for 2.4 only, as this is a subtle behaviour change. If you think it should be backported to 2.3 as well, please indicate so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 From noreply at sourceforge.net Mon Jul 26 15:30:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 15:30:36 2004 Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 23:26 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: mplementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Mon Jul 26 15:41:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 15:41:35 2004 Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 23:26 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: mplementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:41 Message: Logged In: YES user_id=29957 Hm. Pilot error on my part. I had to build once to get graminit.h and graminit.c rebuilt, then rebuild again (after nuking all .o files) to get it to work properly. *sigh* ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Mon Jul 26 15:58:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 15:58:48 2004 Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 23:26 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: mplementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:58 Message: Logged In: YES user_id=29957 I still get a failure in test_transformer after a make distclean and rebuild and make distclean and rebuild. FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_transformer.py", line 37, in ? test_main() File "Lib/test/test_transformer.py", line 32, in test_main test_support.run_unittest( File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_transformer.py", line 16, in testMultipleLHS a = transformer.parse(s) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 50, in parse return Transformer().parsesuite(buf) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 120, in parsesuite return self.transform(parser.suite(text)) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 113, in transform return self.compile_node(tree) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 149, in compile_node return self.file_input(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 180, in file_input self.com_append_stmt(stmts, node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1025, in com_append_stmt result = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 252, in stmt return self.com_stmt(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1018, in com_stmt result = self.lookup_node(node)(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 312, in expr_stmt lval = self.com_augassign(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 922, in com_augassign l = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) KeyError: 268 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:41 Message: Logged In: YES user_id=29957 Hm. Pilot error on my part. I had to build once to get graminit.h and graminit.c rebuilt, then rebuild again (after nuking all .o files) to get it to work properly. *sigh* ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Mon Jul 26 16:09:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 16:10:13 2004 Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 23:26 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: mplementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-27 00:09 Message: Logged In: YES user_id=29957 Argh. Our Makefile's ability to Do The Right Thing... is not good. Rebuilding Lib/symbol.py and Lib/token.py makes this better. The setup.py really should do this automatically. So - all tests pass. As far as I can see, things still to be done for this to be in a2: - Documentation (can wait until a3, I guess) - More coverage in test_decorator (ditto) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:58 Message: Logged In: YES user_id=29957 I still get a failure in test_transformer after a make distclean and rebuild and make distclean and rebuild. FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_transformer.py", line 37, in ? test_main() File "Lib/test/test_transformer.py", line 32, in test_main test_support.run_unittest( File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_transformer.py", line 16, in testMultipleLHS a = transformer.parse(s) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 50, in parse return Transformer().parsesuite(buf) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 120, in parsesuite return self.transform(parser.suite(text)) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 113, in transform return self.compile_node(tree) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 149, in compile_node return self.file_input(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 180, in file_input self.com_append_stmt(stmts, node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1025, in com_append_stmt result = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 252, in stmt return self.com_stmt(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1018, in com_stmt result = self.lookup_node(node)(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 312, in expr_stmt lval = self.com_augassign(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 922, in com_augassign l = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) KeyError: 268 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:41 Message: Logged In: YES user_id=29957 Hm. Pilot error on my part. I had to build once to get graminit.h and graminit.c rebuilt, then rebuild again (after nuking all .o files) to get it to work properly. *sigh* ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Mon Jul 26 16:20:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 16:21:06 2004 Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 14:26 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: mplementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-07-26 15:20 Message: Logged In: YES user_id=6656 Well, PEP 306 is the reference for this sort of thing: also needed (before 2.4 final) are changes to Lib/compiler and tokenize.py. Mark, are you willing/able to work on these? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 15:09 Message: Logged In: YES user_id=29957 Argh. Our Makefile's ability to Do The Right Thing... is not good. Rebuilding Lib/symbol.py and Lib/token.py makes this better. The setup.py really should do this automatically. So - all tests pass. As far as I can see, things still to be done for this to be in a2: - Documentation (can wait until a3, I guess) - More coverage in test_decorator (ditto) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 14:58 Message: Logged In: YES user_id=29957 I still get a failure in test_transformer after a make distclean and rebuild and make distclean and rebuild. FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_transformer.py", line 37, in ? test_main() File "Lib/test/test_transformer.py", line 32, in test_main test_support.run_unittest( File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_transformer.py", line 16, in testMultipleLHS a = transformer.parse(s) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 50, in parse return Transformer().parsesuite(buf) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 120, in parsesuite return self.transform(parser.suite(text)) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 113, in transform return self.compile_node(tree) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 149, in compile_node return self.file_input(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 180, in file_input self.com_append_stmt(stmts, node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1025, in com_append_stmt result = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 252, in stmt return self.com_stmt(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1018, in com_stmt result = self.lookup_node(node)(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 312, in expr_stmt lval = self.com_augassign(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 922, in com_augassign l = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) KeyError: 268 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 14:41 Message: Logged In: YES user_id=29957 Hm. Pilot error on my part. I had to build once to get graminit.h and graminit.c rebuilt, then rebuild again (after nuking all .o files) to get it to work properly. *sigh* ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 14:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Mon Jul 26 16:35:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 16:35:31 2004 Subject: [Patches] [ python-Patches-996316 ] New patch for Python 2.3 spec file. Message-ID: Patches item #996316, was opened at 2004-07-23 12:57 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: New patch for Python 2.3 spec file. Initial Comment: The changes in here probably can be used for the preliminary 2.4 spec file as well. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-27 00:35 Message: Logged In: YES user_id=29957 Applied as Checking in python-2.3.spec; /cvsroot/python/python/dist/src/Misc/RPM/Attic/python-2.3.spec,v <-- python-2.3.spec new revision: 1.2.12.14; previous revision: 1.2.12.13 done Should I just copy this (patched) file to python-2.4.spec, and s/2.3/2.4/ (that's pretty much what the current file is). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-07-23 13:11 Message: Logged In: YES user_id=81797 Grrr. sf.net seems to be having problems with file uploads. It's complaining that the file is <20 bytes or >256KB. Pick up the file from: ftp://ftp.python.org/python/2.3.4/rpms/python-spec-2.3.4-3.patch Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 From MAILsweeper at veepee.com Mon Jul 26 17:41:20 2004 From: MAILsweeper at veepee.com (MAILsweeper@veepee.com) Date: Mon Jul 26 18:05:15 2004 Subject: [Patches] [Indetermine] : Returned mail: Data format error Message-ID: <20040726160514.372E91E4002@bag.python.org> Bonjour, Ceci est une reponse automatique. Le message envoye par l'expediteur : MAILER-DAEMON@python.org et a destination de : patches@python.org ne peut etre lu. Le message a ete mis en quarantaine. From noreply at sourceforge.net Mon Jul 26 18:54:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 18:54:37 2004 Subject: [Patches] [ python-Patches-998149 ] imaplib deleteacl and myrights Message-ID: Patches item #998149, was opened at 2004-07-26 18:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998149&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Arnaud MAZIN (arnaudmz) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib deleteacl and myrights Initial Comment: this small patch against Python-2.3.4 adds two IMAP commands : - deleteacl which allows the cleaning of ACL set by setacl over an IMAP folder - myrights which lists the right that le logged in user has over a folder (which is different from getacl command) Those two features have been tested with SunONE Messaging Server 6.0 and python client 2.3.4 uder linux x86 and Solaris 9 ultrasparc diff -Nru Python-2.3.4.ori/Lib/imaplib.py Python-2.3.4/Lib/imaplib.py > Python-2.3.4-imaplib-deleteacl-myrigths.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998149&group_id=5470 From noreply at sourceforge.net Mon Jul 26 20:53:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 20:54:11 2004 Subject: [Patches] [ python-Patches-996067 ] hp-roman8 codec Message-ID: Patches item #996067, was opened at 2004-07-22 18:00 Message generated for change (Comment added) made by leogah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: M.-A. Lemburg (lemburg) >Summary: hp-roman8 codec Initial Comment: This is a codec for hp-roman generated by munging data from dkuug.dk and running gencodec.py on it. ---------------------------------------------------------------------- >Comment By: Richard Brodie (leogah) Date: 2004-07-26 18:53 Message: Logged In: YES user_id=356893 Reference updated; renamed to hp_roman8.py Aliases: roman8 r8 csHPRoman8 I hesitated with suggesting roman8 as too generic but if it's good enough for IANA... Michael: as far as I can tell, the only problematic ones are the high control characters. Whether 0x80 really corresponds to PAD or is unused is getting a bit esoteric for me. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 10:21 Message: Logged In: YES user_id=38388 One more thing: please also provide a list of common aliases for this codec. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 10:06 Message: Logged In: YES user_id=38388 Richard, could you pleaes remove the copyright notices from the file and instead add a reference and/or explanation of where and how you obtained the data used in the codec. I'll fix the gencodec.py and remove the copyright notices. I used that script to build the initial set of codecs as part of the CNRI contracted work -- while the script is (c) CNRI, the output certainly isn't anymore. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-23 10:00 Message: Logged In: YES user_id=6656 I think the copyright is a bit inaccurate :-) Also, does this do the right thing with unassigned bytes? I didn't think (eg) 0x80 represented a valid character in roman8, could be wrong. Otherwise, looks ok to me... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470 From noreply at sourceforge.net Mon Jul 26 23:47:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jul 26 23:47:23 2004 Subject: [Patches] [ python-Patches-996316 ] New patch for Python 2.3 spec file. Message-ID: Patches item #996316, was opened at 2004-07-23 02:57 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: New patch for Python 2.3 spec file. Initial Comment: The changes in here probably can be used for the preliminary 2.4 spec file as well. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2004-07-26 21:47 Message: Logged In: YES user_id=81797 Yes, copying it to 2.4 and s/2.3/2.4/ should be a good start. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 14:35 Message: Logged In: YES user_id=29957 Applied as Checking in python-2.3.spec; /cvsroot/python/python/dist/src/Misc/RPM/Attic/python-2.3.spec,v <-- python-2.3.spec new revision: 1.2.12.14; previous revision: 1.2.12.13 done Should I just copy this (patched) file to python-2.4.spec, and s/2.3/2.4/ (that's pretty much what the current file is). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-07-23 03:11 Message: Logged In: YES user_id=81797 Grrr. sf.net seems to be having problems with file uploads. It's complaining that the file is <20 bytes or >256KB. Pick up the file from: ftp://ftp.python.org/python/2.3.4/rpms/python-spec-2.3.4-3.patch Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 From noreply at sourceforge.net Tue Jul 27 07:08:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 27 07:08:11 2004 Subject: [Patches] [ python-Patches-998149 ] imaplib deleteacl and myrights Message-ID: Patches item #998149, was opened at 2004-07-26 18:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998149&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Arnaud MAZIN (arnaudmz) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib deleteacl and myrights Initial Comment: this small patch against Python-2.3.4 adds two IMAP commands : - deleteacl which allows the cleaning of ACL set by setacl over an IMAP folder - myrights which lists the right that le logged in user has over a folder (which is different from getacl command) Those two features have been tested with SunONE Messaging Server 6.0 and python client 2.3.4 uder linux x86 and Solaris 9 ultrasparc diff -Nru Python-2.3.4.ori/Lib/imaplib.py Python-2.3.4/Lib/imaplib.py > Python-2.3.4-imaplib-deleteacl-myrigths.patch ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-27 07:08 Message: Logged In: YES user_id=21627 Thanks for the patch. As a new feature, it is unsuitable for 2.3, so I have applied it for 2.4 only: libimaplib.tex 1.27 imaplib.py 1.71 ACKS 1.274 NEWS 1.1055 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998149&group_id=5470 From noreply at sourceforge.net Tue Jul 27 07:23:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 27 07:23:36 2004 Subject: [Patches] [ python-Patches-995766 ] Keyword argument support in cPickle Message-ID: Patches item #995766, was opened at 2004-07-22 10:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword argument support in cPickle Initial Comment: Add keyword argument support to the "dump", "dumps", and "Pickler" callables in the cPickle module. This provides better API compatibility with the pure-Python pickle module. There are several other differences, but this one is probably the most user-visible and likely to be noticed. And it's easy to fix! The callables chosen are those that take multiple arguments. This patch addresses bug #888594 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-07-27 07:23 Message: Logged In: YES user_id=21627 I see. Thanks for the patch; I have applied it as pickletester.py 1.57 NEWS 1.1056 cPickle.c 2.151 ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-26 15:18 Message: Logged In: YES user_id=908995 The patch does what it claims to do--be more compatible with the pure-Python pickle module, which uses "obj" as the first argument. I noticed that when I made the change and should have mentioned it in the initial comment. I intend to submit a patch to the documentation to change the first argument to "obj". Although I think "object" is better, someone might be relying on the pure-Python using obj even though the documentation is wrong about that. I see no reason to backport this to 2.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:16 Message: Logged In: YES user_id=21627 The patch is incorrect: the first argument is called object. Please also double-check consistency with the documentation. I'm going to apply the revised version for 2.4 only, as this is a subtle behaviour change. If you think it should be backported to 2.3 as well, please indicate so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470 From scanmail-notification at basf-it-services.com Tue Jul 27 09:39:54 2004 From: scanmail-notification at basf-it-services.com (scanmail-notification@basf-it-services.com) Date: Tue Jul 27 09:39:59 2004 Subject: [Patches] Returned mail: Data format error ScanMail has blocked your mail due a mail policy. It is not allowed to send executables for security reasons. hat Ihre Mail geblockt. Das Versenden von =?iso-8859-1?q?ausf=FC?= =?iso-8859-1?q?hrbaren_Anh=E4ngen_ist_auf_Grund_von?= Sicherheitsrisiken nicht erlaubt. Message-ID: annette.kauschmann@basf-ag.de BASF's virusscanner has blocked your mail since it contains executable files which may contain viruses and which are therefore blocked in general! If you need to send important files please put them into a zip archive. Der Virenschutz-Scanner der BASF hat die Nachricht geblockt da diese ausf?hrbare Datei(en) enth?lt die Viren enthalten k?nnen und daher grunds?tzlich nicht zugelassen werden! Wenn Sie wichtige Dateien versenden m?ssen so packen Sie diese bitte in ein zip-Archiv. Scanned by ScanMail for Lotus Notes 2.6 SP1 with scanengine 7.000-1004 and pattern version 1.945.00 From noreply at sourceforge.net Tue Jul 27 10:37:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 27 10:38:05 2004 Subject: [Patches] [ python-Patches-994595 ] HTTP basic authentication problem Message-ID: Patches item #994595, was opened at 2004-07-20 16:46 Message generated for change (Comment added) made by c_marinas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Catalin Marinas (c_marinas) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP basic authentication problem Initial Comment: The regular expression matching in the AbstractBasicAuthHandler.http_error_auth_reqed() function in the urllib2 module doesn't work if the authorization string returned by the server contains one or more words in front of 'Basic realm="..."'. The patch changes the rx.match() to rx.search(). ---------------------------------------------------------------------- >Comment By: Catalin Marinas (c_marinas) Date: 2004-07-27 09:37 Message: Logged In: YES user_id=82327 I was trying to access a MS Exchange web mail account through their Outlook Web Access (WebDAV) interface but could not authenticate. The authorisation header returned by the the server is: 'Negotiate, NTLM, Basic realm="..."'. I don't know wheather the MS server complies with any standard, but the patch solved my problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 13:19 Message: Logged In: YES user_id=21627 Can you please give an example of a header that is not correctly detected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 From noreply at sourceforge.net Tue Jul 27 13:23:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 27 13:23:58 2004 Subject: [Patches] [ python-Patches-996159 ] correct urllib2 header capitalization (fix for #994101) Message-ID: Patches item #996159, was opened at 2004-07-22 22:48 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996159&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) Summary: correct urllib2 header capitalization (fix for #994101) Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". The former form is used throughout the module as well. This is incorrect. In this patch I've removed the capitalize() calls and used the correct form throughout both the module.and the tests. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-27 13:23 Message: Logged In: YES user_id=469548 Thanks for the explanation, self-rejecting this one. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-25 20:02 Message: Logged In: YES user_id=261020 The form "User-agent" is not incorrect, merely unconventional (see RFC 2616, section 4.2). The .capitalize() calls were introduced to make headers properly case-insensitive while keeping old code working -- see patch 649742. The problem has arisen because urllib2 recently switched to using httplib.HTTPConnection (and the .request() method in particular, which sends Content-Length automatically) where previously it used httplib.HTTP (which did not send Content- Length automatically). The real problem is that httplib.HTTPConnection.request() sends some headers without checking that they aren't already in the explicitly requested headers. I have submitted patch 997626 to fix this. Thanks for reporting this, Johannes! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996159&group_id=5470 From noreply at sourceforge.net Tue Jul 27 16:08:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 27 16:08:36 2004 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 23:25 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-07-27 10:08 Message: Logged In: YES user_id=11375 Overall I like the patch and wouldn't mind seeing the change become the default behaviour. However, I'm nervous about possibly not understanding the reason the prohibition on zero-length matches was added in the first place. Can you please do some research in the CVS logs and python-dev archives to figure out why the limitation was implemented in the first place? ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 08:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Tue Jul 27 16:11:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jul 27 16:11:52 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 18:50 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 10:11 Message: Logged In: YES user_id=764593 Technically, HTML treats all whitespace (space, tab, newline, carriage return, etc) as interchangable with a single space, except sometimes when you are in a 

 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 16:49:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 16:49:43 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 17:12:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 17:12:41 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 18:28:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 18:28:35 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-12 00:50
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 18:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 17:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 16:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 16:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 08:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 15:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 17:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 06:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 22:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 18:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 18:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 17:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 17:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 15:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 15:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 13:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 15:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 21:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 11:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 11:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 08:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 20:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 20:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 08:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 16:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 06:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 15:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 19:25:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 19:25:47 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 21:55:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 21:55:37 2004
Subject: [Patches] [ python-Patches-997626 ]
	httplib.HTTPConnection.request() bug
Message-ID: 

Patches item #997626, was opened at 2004-07-25 18:56
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.HTTPConnection.request() bug

Initial Comment:
996159 reveals a problem with 
httplib.HTTPConnection.request().

The underlying problem is that, while this method checks 
no explicit Host: header was provided, it fails to do the 
same for Accept-Encoding: and Content-Length:

This patch fixes that.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2004-07-27 20:55

Message:
Logged In: YES 
user_id=261020

OK, I have now tested my patch, and uploaded a new one which
is syntactically correct ;-) along with a patch for the test
I added to test_httplib.py.

No doc changes are required.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 19:09

Message:
Logged In: YES 
user_id=261020

Of course, urllib2 should also be fixed not to add Host and 
Content-Length headers (httplib makes a better job of it), but 
that's a separate bug which I'll file separately.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 19:00

Message:
Logged In: YES 
user_id=261020

This is important to get into 2.4, because it breaks urllib2.

I haven't run the tests yet, or done any manual tests.  I'll try 
and do that tomorrow.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 22:35:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 22:35:32 2004
Subject: [Patches] [ python-Patches-998993 ] Decoding incomplete unicode
Message-ID: 

Patches item #998993, was opened at 2004-07-27 22: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=998993&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decoding incomplete unicode

Initial Comment:
Pythons unicode machinery currently has problems when 
decoding incomplete input.

When codecs.StreamReader.read() encounters a 
decoding error it reads more bytes from the input stream 
and retries decoding. This is broken for two reasons:
1) The error might be due to a malformed byte sequence 
in the input, a problem that can't be fixed by reading 
more bytes.
2) There may be no more bytes available at this time. 
Once more data is available decoding can't continue 
because bytes from the input stream have already been 
read and thrown away.

(sio.DecodingInputFilter has the same problems)

To fix this, three changes are required:
a) We need stateful versions of the decoding functions 
that don't raise "truncated data" exceptions, but decode 
as much as possible and return the position where 
decoding stopped.
b) The StreamReader classes need to use those stateful 
versions of the decoding functions.
c) codecs.StreamReader needs to keep an internal 
buffer with the bytes read from the input stream that 
haven't been decoded into unicode yet.

For a) the Python API already exists: All decoding 
functions in the codecs module return a tuple containing 
the decoded unicode object and the number of bytes 
consumed. But this functionality isn't implemented in the 
decoders:

codec.utf_8_decode(u"a?".encode("utf-8")[:-1])
raises an exception instead of returning (u"a", 1).

This can be fixed by extending the UTF-8 and UTF-16 
decoding functions like this:

PyObject *PyUnicode_DecodeUTF8Stateful(
   const char *s, int size,
   const char *errors, int *consumed)

If consumed == NULL PyUnicode_DecodeUTF8Stateful() 
behaves like PyUnicode_DecodeUTF8() (i.e. it raises 
a "truncated data" exception). If consumed != NULL it 
decodes as much as possible (raising exceptions for 
invalid byte sequences) and puts the number of bytes 
consumed into *consumed.

Additionally for UTF-7 we need to pass the decoder 
state around.

An implementation of c) looks like this:

def read(self, size=-1):
    if size < 0:
        data = self.bytebuffer+self.stream.read()
    else:
        data = self.bytebuffer+self.stream.read(size)
    (object, decodedbytes) = self.decode(data, 
self.errors)
    self.bytebuffer = data[decodedbytes:]
    return object

Unfortunately this changes the semantics. read() might 
return an empty string even if there would be more data 
available. But this can be fixed if we continue reading 
until at least one character is available.

The patch implements a few additional features:
read() has an additional argument chars that can be 
used to specify the number of characters that should be 
returned.

readline() is supported on all readers derived from 
codecs.StreamReader().

readline() and readlines() have an additional option for 
dropping the u"\n".

The patch is still missing changes to the escape codecs
("unicode_escape" and "raw_unicode_escape"), but it
has test cases that check the new functionality for all
affected codecs (UTF-7, UTF-8, UTF-16, UTF-16-LE,
UTF-16-BE).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 22:56:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 22:56:55 2004
Subject: [Patches] [ python-Patches-998993 ] Decoding incomplete unicode
Message-ID: 

Patches item #998993, was opened at 2004-07-27 22:35
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decoding incomplete unicode

Initial Comment:
Pythons unicode machinery currently has problems when 
decoding incomplete input.

When codecs.StreamReader.read() encounters a 
decoding error it reads more bytes from the input stream 
and retries decoding. This is broken for two reasons:
1) The error might be due to a malformed byte sequence 
in the input, a problem that can't be fixed by reading 
more bytes.
2) There may be no more bytes available at this time. 
Once more data is available decoding can't continue 
because bytes from the input stream have already been 
read and thrown away.

(sio.DecodingInputFilter has the same problems)

To fix this, three changes are required:
a) We need stateful versions of the decoding functions 
that don't raise "truncated data" exceptions, but decode 
as much as possible and return the position where 
decoding stopped.
b) The StreamReader classes need to use those stateful 
versions of the decoding functions.
c) codecs.StreamReader needs to keep an internal 
buffer with the bytes read from the input stream that 
haven't been decoded into unicode yet.

For a) the Python API already exists: All decoding 
functions in the codecs module return a tuple containing 
the decoded unicode object and the number of bytes 
consumed. But this functionality isn't implemented in the 
decoders:

codec.utf_8_decode(u"a?".encode("utf-8")[:-1])
raises an exception instead of returning (u"a", 1).

This can be fixed by extending the UTF-8 and UTF-16 
decoding functions like this:

PyObject *PyUnicode_DecodeUTF8Stateful(
   const char *s, int size,
   const char *errors, int *consumed)

If consumed == NULL PyUnicode_DecodeUTF8Stateful() 
behaves like PyUnicode_DecodeUTF8() (i.e. it raises 
a "truncated data" exception). If consumed != NULL it 
decodes as much as possible (raising exceptions for 
invalid byte sequences) and puts the number of bytes 
consumed into *consumed.

Additionally for UTF-7 we need to pass the decoder 
state around.

An implementation of c) looks like this:

def read(self, size=-1):
    if size < 0:
        data = self.bytebuffer+self.stream.read()
    else:
        data = self.bytebuffer+self.stream.read(size)
    (object, decodedbytes) = self.decode(data, 
self.errors)
    self.bytebuffer = data[decodedbytes:]
    return object

Unfortunately this changes the semantics. read() might 
return an empty string even if there would be more data 
available. But this can be fixed if we continue reading 
until at least one character is available.

The patch implements a few additional features:
read() has an additional argument chars that can be 
used to specify the number of characters that should be 
returned.

readline() is supported on all readers derived from 
codecs.StreamReader().

readline() and readlines() have an additional option for 
dropping the u"\n".

The patch is still missing changes to the escape codecs
("unicode_escape" and "raw_unicode_escape"), but it
has test cases that check the new functionality for all
affected codecs (UTF-7, UTF-8, UTF-16, UTF-16-LE,
UTF-16-BE).

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-27 22:56

Message:
Logged In: YES 
user_id=38388

Walter, I think you should split this into multiple feature
requests.

First of all, I agree that the current situation with
StreamReader on malformed input is not really ideal.
However, I don't think we need to fix anything in terms of
adding new interfaces. Also, introducing state at the
encode/decode breaks the design of the codecs functions --
only StreamReader/Writer may maintain state.

Now, the situation is not that bad though: the case of a
codec continuing as far as possible and then returning the
decoded data as well as the number of bytes consumed is
basically just another error handling scheme. Let's call it
"break". If errors is set to "break", the codec will stop
decoding/encoding and return the coded data as well as the
number of input characters consumed.

You could then use this scheme in the StreamWriter/Reader to
implement the "read as far as possible" scheme.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 23:11:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 23:11:09 2004
Subject: [Patches] [ python-Patches-998993 ] Decoding incomplete unicode
Message-ID: 

Patches item #998993, was opened at 2004-07-27 22:35
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D?rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decoding incomplete unicode

Initial Comment:
Pythons unicode machinery currently has problems when 
decoding incomplete input.

When codecs.StreamReader.read() encounters a 
decoding error it reads more bytes from the input stream 
and retries decoding. This is broken for two reasons:
1) The error might be due to a malformed byte sequence 
in the input, a problem that can't be fixed by reading 
more bytes.
2) There may be no more bytes available at this time. 
Once more data is available decoding can't continue 
because bytes from the input stream have already been 
read and thrown away.

(sio.DecodingInputFilter has the same problems)

To fix this, three changes are required:
a) We need stateful versions of the decoding functions 
that don't raise "truncated data" exceptions, but decode 
as much as possible and return the position where 
decoding stopped.
b) The StreamReader classes need to use those stateful 
versions of the decoding functions.
c) codecs.StreamReader needs to keep an internal 
buffer with the bytes read from the input stream that 
haven't been decoded into unicode yet.

For a) the Python API already exists: All decoding 
functions in the codecs module return a tuple containing 
the decoded unicode object and the number of bytes 
consumed. But this functionality isn't implemented in the 
decoders:

codec.utf_8_decode(u"a?".encode("utf-8")[:-1])
raises an exception instead of returning (u"a", 1).

This can be fixed by extending the UTF-8 and UTF-16 
decoding functions like this:

PyObject *PyUnicode_DecodeUTF8Stateful(
   const char *s, int size,
   const char *errors, int *consumed)

If consumed == NULL PyUnicode_DecodeUTF8Stateful() 
behaves like PyUnicode_DecodeUTF8() (i.e. it raises 
a "truncated data" exception). If consumed != NULL it 
decodes as much as possible (raising exceptions for 
invalid byte sequences) and puts the number of bytes 
consumed into *consumed.

Additionally for UTF-7 we need to pass the decoder 
state around.

An implementation of c) looks like this:

def read(self, size=-1):
    if size < 0:
        data = self.bytebuffer+self.stream.read()
    else:
        data = self.bytebuffer+self.stream.read(size)
    (object, decodedbytes) = self.decode(data, 
self.errors)
    self.bytebuffer = data[decodedbytes:]
    return object

Unfortunately this changes the semantics. read() might 
return an empty string even if there would be more data 
available. But this can be fixed if we continue reading 
until at least one character is available.

The patch implements a few additional features:
read() has an additional argument chars that can be 
used to specify the number of characters that should be 
returned.

readline() is supported on all readers derived from 
codecs.StreamReader().

readline() and readlines() have an additional option for 
dropping the u"\n".

The patch is still missing changes to the escape codecs
("unicode_escape" and "raw_unicode_escape"), but it
has test cases that check the new functionality for all
affected codecs (UTF-7, UTF-8, UTF-16, UTF-16-LE,
UTF-16-BE).

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-27 23:11

Message:
Logged In: YES 
user_id=21627

Marc-Andre, can you please specifically point to the places
in the patch where it violates the principles you have
stated? E.g. where does it maintain state outside the
StreamReader/Writer?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-27 22:56

Message:
Logged In: YES 
user_id=38388

Walter, I think you should split this into multiple feature
requests.

First of all, I agree that the current situation with
StreamReader on malformed input is not really ideal.
However, I don't think we need to fix anything in terms of
adding new interfaces. Also, introducing state at the
encode/decode breaks the design of the codecs functions --
only StreamReader/Writer may maintain state.

Now, the situation is not that bad though: the case of a
codec continuing as far as possible and then returning the
decoded data as well as the number of bytes consumed is
basically just another error handling scheme. Let's call it
"break". If errors is set to "break", the codec will stop
decoding/encoding and return the coded data as well as the
number of input characters consumed.

You could then use this scheme in the StreamWriter/Reader to
implement the "read as far as possible" scheme.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 23:46:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 23:47:01 2004
Subject: [Patches] [ python-Patches-996067 ] hp-roman8 codec
Message-ID: 

Patches item #996067, was opened at 2004-07-22 20:00
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brodie (leogah)
Assigned to: M.-A. Lemburg (lemburg)
Summary: hp-roman8 codec

Initial Comment:
This is a codec for hp-roman generated by munging data 
from dkuug.dk and running gencodec.py on it.  
 
 
 

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-27 23:46

Message:
Logged In: YES 
user_id=38388

Looks good. I'll add the codec tomorrow.

Thanks !

----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2004-07-26 20:53

Message:
Logged In: YES 
user_id=356893

Reference updated; renamed to hp_roman8.py 
 
Aliases: roman8 r8 csHPRoman8 
 
I hesitated with suggesting roman8 as too generic but if it's 
good enough for IANA... 
 
Michael: as far as I can tell, the only problematic ones are the 
high control characters. Whether 0x80 really corresponds to 
PAD or is unused is getting a bit esoteric for me.  

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:21

Message:
Logged In: YES 
user_id=38388

One more thing: please also provide a list of common aliases
for this codec. Thanks.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:06

Message:
Logged In: YES 
user_id=38388

Richard, could you pleaes remove the copyright notices from
the file
and instead add a reference and/or explanation of where and how
you obtained the data used in the codec.

I'll fix the gencodec.py and remove the copyright notices. I
used
that script to build the initial set of codecs as part of
the CNRI
contracted work -- while the script is (c) CNRI, the output
certainly
isn't anymore.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-23 12:00

Message:
Logged In: YES 
user_id=6656

I think the copyright is a bit inaccurate :-)

Also, does this do the right thing with unassigned bytes?  I didn't 
think (eg) 0x80 represented a valid character in roman8, could be 
wrong.

Otherwise, looks ok to me...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 05:19:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 05:19:38 2004
Subject: [Patches] [ python-Patches-976162 ] Deferred String Addtion:
	Proof-of-concept
Message-ID: 

Patches item #976162, was opened at 2004-06-20 06:10
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deferred String Addtion:  Proof-of-concept

Initial Comment:
The attached patch demonstrats a possible
implementation for 
deferred string addition.  The idea is to have
str.__add__ save references to its inputs rather that
do the concatenation immediately.  The moment some
other method needs the full string, it is generated
recursively so that the whole concatenation can be done
with a single join.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-27 23:19

Message:
Logged In: YES 
user_id=6380

Nice to have this, but no point in keeping it open forever -- it 
will never be applied.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-22 00:28

Message:
Logged In: YES 
user_id=80475

The patch is not meant to be loaded to UserString.  Rather
it is a proof-of-concept demonstration of how deferred
string addition would work. Even it pure python form, it
shows how to convert an O(n**2) process to O(n).  If the
concept is approved, the goal is to alter the C code for
stringobject.c, unicodeobject.c, and to make a more thorough
version for UserString.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-21 10:31

Message:
Logged In: YES 
user_id=764593

There is an implicit assumption that any component/part with 
its own 'components' attribute will be another UserString (or, 
at the very least, will act like one when traversed).

Would it be better to check whether the subobject actually is 
a UserString (since new-style objects can freely use multiple 
inheritance), or to do some sort of guard in add?  (Perhaps 
immediately stringifying anything with a components attribute 
that is not a UserString?)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976162&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 05:22:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 05:23:03 2004
Subject: [Patches] [ python-Patches-979728 ] mplementation for PEP 318 using
	java-style syntax
Message-ID: 

Patches item #979728, was opened at 2004-06-25 09:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
Assigned to: Nobody/Anonymous (nobody)
Summary: mplementation for PEP 318 using java-style syntax

Initial Comment:
This implements function decorators using the
Java-style syntax described in
http://mail.python.org/pipermail/python-dev/2004-June/045516.html

As the patch changes the grammar, you'll need to
make sure Include/graminit.h and Python/graminit.c
are writable after applying the patch but before
compiling (after a standard CVS checkout they are
read-only, which stops pgen from working).

Changes: 

   - adding @ as a token
   - changing the grammer for funcdef
   - adding com_decorator in compile.c
   - adding test_decorator.py (based on Guido's version)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-27 23:22

Message:
Logged In: YES 
user_id=6380

Before 2.4final I'd like to see some changes to the syntax:

- Instead of @test, it should be somewhat more restricted, 
preferably @ followed by a dotted name followed by an 
optional argument list. @1+2 or @[1,2,3] just doesn't make 
sense IMO.

- I'd like there to always be a newline between the last 
decorator and the 'def' keyword. (This in the sake 
of "greppability" per python-dev discussion.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-26 10:20

Message:
Logged In: YES 
user_id=6656

Well, PEP 306 is the reference for this sort of thing: also
needed (before 2.4 final) are changes to Lib/compiler and
tokenize.py.  Mark, are you willing/able to work on these?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 10:09

Message:
Logged In: YES 
user_id=29957

Argh. Our Makefile's ability to Do The Right Thing... is not
good. Rebuilding Lib/symbol.py and Lib/token.py makes this
better. The setup.py really should do this automatically.

So - all tests pass. As far as I can see, things still to be
done for this to be in a2:

- Documentation (can wait until a3, I guess)
- More coverage in test_decorator (ditto)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 09:58

Message:
Logged In: YES 
user_id=29957

I still get a failure in test_transformer after a make
distclean and rebuild and make distclean and rebuild.

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 37, in ?
    test_main()
  File "Lib/test/test_transformer.py", line 32, in test_main
    test_support.run_unittest(
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
    run_suite(suite, testclass)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 16, in
testMultipleLHS
    a = transformer.parse(s)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 113, in transform
    return self.compile_node(tree)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 149, in compile_node
    return self.file_input(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 180, in file_input
    self.com_append_stmt(stmts, node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1025, in com_append_stmt
    result = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 252, in stmt
    return self.com_stmt(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1018, in com_stmt
    result = self.lookup_node(node)(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 312, in expr_stmt
    lval = self.com_augassign(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 922, in com_augassign
    l = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
KeyError: 268


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 09:41

Message:
Logged In: YES 
user_id=29957

Hm. Pilot error on my part. I had to build once to get
graminit.h and graminit.c rebuilt, then rebuild again (after
nuking all .o files) to get it to work properly. *sigh*


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 09:30

Message:
Logged In: YES 
user_id=29957

After applying this patch, any attempts to use the
newly-built python (I deleted graminit.c and graminit.h, to
make sure they were rebuilt) gives the following on any
'import':

*-s*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py -q build;; *)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py build;; esac
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt, imp, re
SystemError: compile_node: unexpected node type
make: *** [sharedmods] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 05:39:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 05:39:37 2004
Subject: [Patches] [ python-Patches-979728 ] Implementation for PEP 318
	using java-style syntax
Message-ID: 

Patches item #979728, was opened at 2004-06-25 09:26
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Implementation for PEP 318 using java-style syntax

Initial Comment:
This implements function decorators using the
Java-style syntax described in
http://mail.python.org/pipermail/python-dev/2004-June/045516.html

As the patch changes the grammar, you'll need to
make sure Include/graminit.h and Python/graminit.c
are writable after applying the patch but before
compiling (after a standard CVS checkout they are
read-only, which stops pgen from working).

Changes: 

   - adding @ as a token
   - changing the grammer for funcdef
   - adding com_decorator in compile.c
   - adding test_decorator.py (based on Guido's version)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-27 23:39

Message:
Logged In: YES 
user_id=6380

There's some non-standard C: in compile.c line 5641 there's a 
char* declaration that isn't at the start of a block. Easily 
fixed but should definitely be fixed before releasing a2.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-27 23:22

Message:
Logged In: YES 
user_id=6380

Before 2.4final I'd like to see some changes to the syntax:

- Instead of @test, it should be somewhat more restricted, 
preferably @ followed by a dotted name followed by an 
optional argument list. @1+2 or @[1,2,3] just doesn't make 
sense IMO.

- I'd like there to always be a newline between the last 
decorator and the 'def' keyword. (This in the sake 
of "greppability" per python-dev discussion.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-26 10:20

Message:
Logged In: YES 
user_id=6656

Well, PEP 306 is the reference for this sort of thing: also
needed (before 2.4 final) are changes to Lib/compiler and
tokenize.py.  Mark, are you willing/able to work on these?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 10:09

Message:
Logged In: YES 
user_id=29957

Argh. Our Makefile's ability to Do The Right Thing... is not
good. Rebuilding Lib/symbol.py and Lib/token.py makes this
better. The setup.py really should do this automatically.

So - all tests pass. As far as I can see, things still to be
done for this to be in a2:

- Documentation (can wait until a3, I guess)
- More coverage in test_decorator (ditto)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 09:58

Message:
Logged In: YES 
user_id=29957

I still get a failure in test_transformer after a make
distclean and rebuild and make distclean and rebuild.

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 37, in ?
    test_main()
  File "Lib/test/test_transformer.py", line 32, in test_main
    test_support.run_unittest(
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
    run_suite(suite, testclass)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 16, in
testMultipleLHS
    a = transformer.parse(s)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 113, in transform
    return self.compile_node(tree)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 149, in compile_node
    return self.file_input(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 180, in file_input
    self.com_append_stmt(stmts, node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1025, in com_append_stmt
    result = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 252, in stmt
    return self.com_stmt(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1018, in com_stmt
    result = self.lookup_node(node)(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 312, in expr_stmt
    lval = self.com_augassign(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 922, in com_augassign
    l = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
KeyError: 268


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 09:41

Message:
Logged In: YES 
user_id=29957

Hm. Pilot error on my part. I had to build once to get
graminit.h and graminit.c rebuilt, then rebuild again (after
nuking all .o files) to get it to work properly. *sigh*


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 09:30

Message:
Logged In: YES 
user_id=29957

After applying this patch, any attempts to use the
newly-built python (I deleted graminit.c and graminit.h, to
make sure they were rebuilt) gives the following on any
'import':

*-s*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py -q build;; *)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py build;; esac
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt, imp, re
SystemError: compile_node: unexpected node type
make: *** [sharedmods] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 11:18:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 11:18:34 2004
Subject: [Patches] [ python-Patches-999280 ] Update kwargs in pickle docs to
	match implementations
Message-ID: 

Patches item #999280, was opened at 2004-07-28 09: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=999280&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update kwargs in pickle docs to match implementations

Initial Comment:
The pickle documentation says that the first argument to dump 
and dumps is called "object", but both the pure-Python pickle 
module and (now) the cPickle module call it "obj". The pickle 
module purposely calls it "obj" instead of "object" to avoid 
shadowing the "object" builtin, and the cPickle does likewise to 
maintain API compatibility.

References: pickle.py 1.107, SF #995766

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=999280&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 11:22:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 11:22:19 2004
Subject: [Patches] [ python-Patches-995766 ] Keyword argument support in
	cPickle
Message-ID: 

Patches item #995766, was opened at 2004-07-22 08:25
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Keyword argument support in cPickle

Initial Comment:
Add keyword argument support to the "dump", "dumps", and 
"Pickler"
callables in the cPickle module. This provides better API
compatibility with the pure-Python pickle module. There are 
several
other differences, but this one is probably the most user-visible 
and
likely to be noticed. And it's easy to fix! The callables chosen are
those that take multiple arguments.

This patch addresses bug #888594


----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-28 09:22

Message:
Logged In: YES 
user_id=908995

Thanks Martin. I submitted the documentation update as SF #999280, 
and this patch addressed bug #888594, which can now be closed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-27 05:23

Message:
Logged In: YES 
user_id=21627

I see. Thanks for the patch; I have applied it as 

pickletester.py 1.57
NEWS 1.1056
cPickle.c 2.151


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-26 13:18

Message:
Logged In: YES 
user_id=908995

The patch does what it claims to do--be more compatible with the 
pure-Python pickle module, which uses "obj" as the first argument. I noticed 
that when I made the change and should have mentioned it in the initial 
comment. I intend to submit a patch to the documentation to change the first 
argument to "obj". Although I think "object" is better, someone might be 
relying on the pure-Python using obj even though the documentation is wrong 
about that.

I see no reason to backport this to 2.3.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-26 12:16

Message:
Logged In: YES 
user_id=21627

The patch is incorrect: the first argument is called object.
Please also double-check consistency with the documentation.

I'm going to apply the revised version for 2.4 only, as this
is a subtle behaviour change. If you think it should be
backported to 2.3 as well, please indicate so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995766&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 17:38:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 17:38:58 2004
Subject: [Patches] [ python-Patches-996067 ] hp-roman8 codec
Message-ID: 

Patches item #996067, was opened at 2004-07-22 20:00
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Richard Brodie (leogah)
Assigned to: M.-A. Lemburg (lemburg)
Summary: hp-roman8 codec

Initial Comment:
This is a codec for hp-roman generated by munging data 
from dkuug.dk and running gencodec.py on it.  
 
 
 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-27 23:46

Message:
Logged In: YES 
user_id=38388

Looks good. I'll add the codec tomorrow.

Thanks !

----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2004-07-26 20:53

Message:
Logged In: YES 
user_id=356893

Reference updated; renamed to hp_roman8.py 
 
Aliases: roman8 r8 csHPRoman8 
 
I hesitated with suggesting roman8 as too generic but if it's 
good enough for IANA... 
 
Michael: as far as I can tell, the only problematic ones are the 
high control characters. Whether 0x80 really corresponds to 
PAD or is unused is getting a bit esoteric for me.  

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:21

Message:
Logged In: YES 
user_id=38388

One more thing: please also provide a list of common aliases
for this codec. Thanks.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:06

Message:
Logged In: YES 
user_id=38388

Richard, could you pleaes remove the copyright notices from
the file
and instead add a reference and/or explanation of where and how
you obtained the data used in the codec.

I'll fix the gencodec.py and remove the copyright notices. I
used
that script to build the initial set of codecs as part of
the CNRI
contracted work -- while the script is (c) CNRI, the output
certainly
isn't anymore.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-23 12:00

Message:
Logged In: YES 
user_id=6656

I think the copyright is a bit inaccurate :-)

Also, does this do the right thing with unassigned bytes?  I didn't 
think (eg) 0x80 represented a valid character in roman8, could be 
wrong.

Otherwise, looks ok to me...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996067&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 18:23:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 18:23:37 2004
Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for
	#852532)
Message-ID: 

Patches item #988761, was opened at 2004-07-10 22:25
Message generated for change (Comment added) made by mkc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.split emptyok flag (fix for #852532)

Initial Comment:
This patch addresses bug #852532.  The underlying
problem is that re.split ignores any match it makes
that has length zero, which blocks a number of useful
possibilities.  The attached patch implements a flag
'emptyok', which if set to True, causes re.split to 
allow zero length matches.

My preference would be to just change the behavior of
re.split, rather than adding this flag.  The old
behavior isn't documented (though a couple of cases in
test_re.py do depend on it).  As a practical matter,
though, I realize that there may be some code out there
relying on this undocumented behavior.  And I'm hoping
that this useful feature can be added quickly.  Perhaps
this new behavior could be made the default in a future
version of Python.

(Linux 2.6.3 i686)

----------------------------------------------------------------------

>Comment By: Mike Coleman (mkc)
Date: 2004-07-28 11:23

Message:
Logged In: YES 
user_id=555

I picked through CVS, python-dev and google and came up with
this.  The current behavior was present way back in the
earliest regsub.py in CVS (dated Sep 1992); subsequent
implementation seem to be mirroring this behavior.  The CVS
comment back in 1992 described split as modeled on nawk.  A
check of nawk(1) confirms that nawk only splits on non-null
matches.  Perl (circa 5.6) on the other hand, appears to
split the way this patch does (though I wasn't aware of that
when I wrote the patch) so that might argue in the other
direction.  I would note, too, that re.findall and
re.finditer tend in this direction ("Empty matches are
included in the result unless they touch the beginning of
another match.").

The python-dev archive doesn't seem to go back far enough to
be relevant and I'm not sure how to search it.  General
googling (python "re.split" empty match) found a few hits. 
Probably the most relevant is Tim Peters saying "Python
won't change here (IMO)" and giving the example that he also
gives in a comment to bug #852532 (which this patch
addresses).  He also wonders in his comment about the
possibility of a "design constraint", but I think this patch
addresses that concern.

As far as I can tell, the current behavior was a design
decision made over 10 years ago, between two alternatives
that probably didn't matter much at the time.  Skipping
empty matches probably seemed harmless before
lookahead/lookbehind assertions.  Now, though, the current
behavior seems like a significant hindrance.  Furthermore,
it ought to be pretty trivial to modify any existing
patterns to get the old behavior, should that be desired
(e.g., use 'x+' instead of 'x*').

(I didn't notice that re.findall doc when I originally wrote
this patch.  Perhaps the doc in the patch should be slightly
modified to help emphasize the similarity between how
re.findall and re.split handle empty matches.)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-27 09:08

Message:
Logged In: YES 
user_id=11375

Overall I like the patch and wouldn't mind seeing the change
become the default behaviour.  However, I'm nervous about
possibly not understanding the reason the prohibition on
zero-length matches was added in the first place.  Can you
please do some research in the CVS logs and python-dev
archives to figure out why the limitation was implemented in
the first place?


----------------------------------------------------------------------

Comment By: Chris King (colander_man)
Date: 2004-07-21 07:46

Message:
Logged In: YES 
user_id=573252

Practical example where the current behaviour produces
undesirable results (splitting on character transitions):

>>> import re
>>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring')
['SOMEstring']    # desired is ['SOME','string']

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 19:37:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 19:37:58 2004
Subject: [Patches] [ python-Patches-979728 ] Implementation for PEP 318
	using java-style syntax
Message-ID: 

Patches item #979728, was opened at 2004-06-25 13:26
Message generated for change (Comment added) made by mark_t_russell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implementation for PEP 318 using java-style syntax

Initial Comment:
This implements function decorators using the
Java-style syntax described in
http://mail.python.org/pipermail/python-dev/2004-June/045516.html

As the patch changes the grammar, you'll need to
make sure Include/graminit.h and Python/graminit.c
are writable after applying the patch but before
compiling (after a standard CVS checkout they are
read-only, which stops pgen from working).

Changes: 

   - adding @ as a token
   - changing the grammer for funcdef
   - adding com_decorator in compile.c
   - adding test_decorator.py (based on Guido's version)


----------------------------------------------------------------------

>Comment By: Mark Russell (mark_t_russell)
Date: 2004-07-28 17:37

Message:
Logged In: YES 
user_id=1017234

I've added an updated version of the patch, with the
following changes:

     - Applied against CVS head (as of 2004-07-28)
     - Non-standard C removed (see Guido's comment)
     - Newline before the def is now mandatory
     - Grammer for decorator expressions more restricted
     - tokenize.py and test_tokenize updated to handle @ tokens
     - Lib/compiler/transformer.py minimally updated

Still to do:

     - Complete work on Lib/compiler (i.e. get it to the
point where it
       produces a correct .pyc for code with decorators).
     - Write docs
     - Work through all the steps in PEP 306
     - Add more regression tests to test_decorator

I can put in some time on this in the next few days if this
patch seems likely
to be applied.

The grammar is now:

     decorator: '@' dotted_name [ '(' [arglist] ')' ]
     decorators: decorator ([NEWLINE] decorator)* NEWLINE
     funcdef: [decorators] 'def' NAME parameters ':' suite

This allows

     @foo @bar
     def f(): pass

but not:

     @foo @bar def f(): paqss

Issues:

    - Someone should take a look at the "case decorator:"
code in
      symtable_node() in compile.c.  All the tests pass, but
this
      seems a fragile bit of code to be changing

    - Lib/compiler needs some more work - at present
decorators are
      ignored there.  I'll do some more work on this when I
get time
      (probably this weekend).

    - As noted in the comments here, the build system does
not cope
      automatically with grammar changes.  The steps I used
to apply
      the patch are:

	   cd .../dist/src
           patch -p0 < /path/to/patch-file
	   ./configure
	   make
	   chmod +w Lib/symbol.py Lib/token.py
	   ./python Lib/symbol.py
	   ./python Lib/token.py
	   make clean
	   make
	   make test >& make-test.out

       I'm sure this sequence is non-optimal, but it works
for me, and
       all the tests pass on my Linux system afterwards.	   


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-28 03:39

Message:
Logged In: YES 
user_id=6380

There's some non-standard C: in compile.c line 5641 there's a 
char* declaration that isn't at the start of a block. Easily 
fixed but should definitely be fixed before releasing a2.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-28 03:22

Message:
Logged In: YES 
user_id=6380

Before 2.4final I'd like to see some changes to the syntax:

- Instead of @test, it should be somewhat more restricted, 
preferably @ followed by a dotted name followed by an 
optional argument list. @1+2 or @[1,2,3] just doesn't make 
sense IMO.

- I'd like there to always be a newline between the last 
decorator and the 'def' keyword. (This in the sake 
of "greppability" per python-dev discussion.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-26 14:20

Message:
Logged In: YES 
user_id=6656

Well, PEP 306 is the reference for this sort of thing: also
needed (before 2.4 final) are changes to Lib/compiler and
tokenize.py.  Mark, are you willing/able to work on these?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 14:09

Message:
Logged In: YES 
user_id=29957

Argh. Our Makefile's ability to Do The Right Thing... is not
good. Rebuilding Lib/symbol.py and Lib/token.py makes this
better. The setup.py really should do this automatically.

So - all tests pass. As far as I can see, things still to be
done for this to be in a2:

- Documentation (can wait until a3, I guess)
- More coverage in test_decorator (ditto)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 13:58

Message:
Logged In: YES 
user_id=29957

I still get a failure in test_transformer after a make
distclean and rebuild and make distclean and rebuild.

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 37, in ?
    test_main()
  File "Lib/test/test_transformer.py", line 32, in test_main
    test_support.run_unittest(
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
    run_suite(suite, testclass)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 16, in
testMultipleLHS
    a = transformer.parse(s)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 113, in transform
    return self.compile_node(tree)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 149, in compile_node
    return self.file_input(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 180, in file_input
    self.com_append_stmt(stmts, node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1025, in com_append_stmt
    result = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 252, in stmt
    return self.com_stmt(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1018, in com_stmt
    result = self.lookup_node(node)(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 312, in expr_stmt
    lval = self.com_augassign(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 922, in com_augassign
    l = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
KeyError: 268


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 13:41

Message:
Logged In: YES 
user_id=29957

Hm. Pilot error on my part. I had to build once to get
graminit.h and graminit.c rebuilt, then rebuild again (after
nuking all .o files) to get it to work properly. *sigh*


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 13:30

Message:
Logged In: YES 
user_id=29957

After applying this patch, any attempts to use the
newly-built python (I deleted graminit.c and graminit.h, to
make sure they were rebuilt) gives the following on any
'import':

*-s*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py -q build;; *)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py build;; esac
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt, imp, re
SystemError: compile_node: unexpected node type
make: *** [sharedmods] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 21:39:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 21:39:45 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 23:36:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 23:36:53 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 00:02:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 00:02:49 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 00:41:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 00:41:44 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 18:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 18:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 16:32:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 18:04:18 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 19:13:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 20:04:32 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 20:52:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 20:52:54 2004
Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4
	implementation
Message-ID: 

Patches item #1000267, was opened at 2004-07-29 13:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: chads (cjschr)
Assigned to: Nobody/Anonymous (nobody)
Summary: A BSD-style wait4 implementation

Initial Comment:
A BSD-style wait4 implementation.

Using existing code from the posixmodule.c and
resource.c files,
I threw together a patch that implements the wait4
function.

This function is similar to waitpid, but it also
returns usage information
about the child process.

wait4(pid, options) -> (pid, status, rusage)

It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes
using
Python-2.3.4.

The patch may need some fine tuning.

Thanks
Chad

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 21:37:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 21:37:40 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 22:10:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 22:10:12 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From Madge at otakumail.com  Sat Jul 31 17:26:46 2004
From: Madge at otakumail.com (Madge@otakumail.com)
Date: Sat Jul 31 01:24:18 2004
Subject: [Patches] Mature shows big boobs and rides cock!...delude 
Message-ID: <9687esw6g34pv$01zp42b9q43$622ml402g@contradictory.futbolamericano.com>

>Nah every big head get sense.
>Seeing is believing

This blond old sweetie is ready to show some action. 
She s got enough experience to blow your fucking mind away. 
She asked that boy to satisfy her enormous thirst of fucking. 
Fucking hard, real hard. 
But most of all, she loves having a pretty boy standing of his knees smelling her 
wide opened vagina and licking her swollen clit just like you ll see it in here. 
She s crazy! This homepage right here: http://web.maturevideo.info/2/

Stop sendings here: http://bidden.mature-asskickers.info/ma.php?something
>It is a long lane that has no turning
>Count your blessings
From Eugenia at gmx.de  Sat Jul 31 19:13:40 2004
From: Eugenia at gmx.de (Eugenia@gmx.de)
Date: Sat Jul 31 03:20:00 2004
Subject: [Patches] Sexy mom rids this young cock!...scenery 
Message-ID: <0221dqe9ag0ps$20ui89d2p83$575s1zwq@unidirectional.melodymail.com>

>He is an ill companion that has a good memory 
>There is no time like the present

These old horny lesbians love playing games using kinky toys pushing them really deep. 
They love clit-licking. 
Clit-licking is great when one girl does it for another with an outstanding pleasure. 
Girls know how to do each other much better than boys, especially old ladies like these two whores. 
Their tongue-to-clit scene won t leave you indefinite to it and nasty, but so lovely moms. 
Some very hot samples here: http://murderous.maturestudents.info/1/

Uncubscribers-link here: http://transpond.mature-action.info/ma.php?astm
>Good things come in small packages.
>A penny saved makes Jack a dull boy.
>The old believe everything, the middle aged suspect everything, the young know everything
From noreply at sourceforge.net  Sat Jul 31 10:24:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 10:24:33 2004
Subject: [Patches] [ python-Patches-1001109 ] posixpath._resolve_link typo
Message-ID: 

Patches item #1001109, was opened at 2004-07-31 10:24
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=1001109&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixpath._resolve_link typo

Initial Comment:
_resolvelink calls abspath to test if a path is absolute, that should 
obviously be a call to isabs.

Without this patch os.path.realpath returns the wrong result when 
the link contents is a relative path.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001109&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 10:25:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 10:25:43 2004
Subject: [Patches] [ python-Patches-1001109 ] posixpath._resolve_link typo
Message-ID: 

Patches item #1001109, was opened at 2004-07-31 10:24
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001109&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixpath._resolve_link typo

Initial Comment:
_resolvelink calls abspath to test if a path is absolute, that should 
obviously be a call to isabs.

Without this patch os.path.realpath returns the wrong result when 
the link contents is a relative path.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-07-31 10:25

Message:
Logged In: YES 
user_id=580910

Stupid SF interface, I forgot to check the upload box :-(

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001109&group_id=5470
From qeen at 123123.servegame.com  Sat Jul 31 20:21:05 2004
From: qeen at 123123.servegame.com (qeen@123123.servegame.com)
Date: Sat Jul 31 20:21:07 2004
Subject: [Patches] =?utf-8?b?wpBswo3DiMKDQcKDaMKDwozCg1jCksKg?=
Message-ID: mag20040731221228

人妻アドレス帳

*:･｡,☆ﾟ'･:*:･｡,★ 人妻マガジン 第16号　*:･｡,☆ﾟ'･:*:･｡,★

こんばんは、管理人のヽ(τωヽ)ﾉ ﾓｳﾀﾞﾒﾎﾟです。
またまた台風が来ましたね。今回のは通常とは逆の動きをしましたね。
変だなぁ〜とおもわれた人も多いかと思います。
気象庁によれば高気圧が北日本にあるために台風が北上出来ずに北西に向かったということでした。
でも、高気圧って台風より力があるのでしょうか？
私はとても疑問に思います。私は関東には何か強い力がかかっていて台風が近寄れなかったのでは？
と思っています。進路も現在大地震が懸念されている地域を通過していますし、
前回の台風もそうでした。そろそろ何かが起こりそうな気がしてなりません。
皆さんもいざというときの為に準備はしておいたほうがいいかも知れません。

私ことヽ(τωヽ)ﾉ ﾓｳﾀﾞﾒﾎﾟは只今ジオラマ作りにハマっているのでかなり寝不足です。
本日はもう寝ます････　皆さんおやすみなさい！

◆◇｡.:*･゜川nVvV从◆◇ηﾟ･*:.｡｡.:*･゜川nVvV从◆◇ηﾟ･*:.｡｡.:*･゜川nVvV从◆◇


夏休みも本番です。ギャル〜熟女まで幅広い年齢層が特徴の老舗サイトの決定版！
気分に合わせて女性が選べるのがいいですね。
http://veryvery.myftp.org/?g02
しかも！最高にお得なキャンペーン中です！絶対に今がチャンス！
ギャルゲットには最高の季節です！
今すぐココから登録！
↓↓↓↓↓↓↓↓↓↓
http://veryvery.myftp.org/?g02

※　不当請求や同時登録等はございませんので安心してご利用ください。


◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇

日本最大級!?のポータルサイトがリニューアル・オープンです。
真面目な運営を基本に安心してご利用いただけますよう努力を続けています。
http://service777.hopto.org/?g02
出会えるサイトばかりを集めたリンク集なので選ぶのはあなたです！
更に検索等の機能も充実で満足度２００％間違いなし！
雑誌等の宣伝効果で人気急上昇です！ハイッ！
http://service777.hopto.org/?g02
是非！ブックマークしてね！


◆◇｡.:*･゜川nVvV从◆◇ηﾟ･*:.｡｡.:*･゜川nVvV从◆◇ηﾟ･*:.｡｡.:*･゜川nVvV从◆◇

無関係な方へ配信されました場合は、ご迷惑をおかけし、大変申し訳ございません。
御手数ですが削除して頂きますよう様お願い致します。

解除の場合はこのまま返信してください。

From noreply at sourceforge.net  Sat Jul 31 23:49:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 23:49:50 2004
Subject: [Patches] [ python-Patches-979728 ] Implementation for PEP 318
	using java-style syntax
Message-ID: 

Patches item #979728, was opened at 2004-06-25 13:26
Message generated for change (Comment added) made by mark_t_russell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implementation for PEP 318 using java-style syntax

Initial Comment:
This implements function decorators using the
Java-style syntax described in
http://mail.python.org/pipermail/python-dev/2004-June/045516.html

As the patch changes the grammar, you'll need to
make sure Include/graminit.h and Python/graminit.c
are writable after applying the patch but before
compiling (after a standard CVS checkout they are
read-only, which stops pgen from working).

Changes: 

   - adding @ as a token
   - changing the grammer for funcdef
   - adding com_decorator in compile.c
   - adding test_decorator.py (based on Guido's version)


----------------------------------------------------------------------

>Comment By: Mark Russell (mark_t_russell)
Date: 2004-07-31 21:49

Message:
Logged In: YES 
user_id=1017234

I've updated the patch again.  See my previous
comment here for the procedure to apply the patch.

Main changes:

     - Added decorator support to Lib/compiler.
       test_decorators.py now passes when compiled
       with Lib/compiler.  The regression tests
       also pass when built with
       Tools/compiler/regrtest.py, apart from
       test_dis.py which I assume is due to
       trivial differences in the bytecode output.
       
     - Added a description of decorators to the
       reference manual.  Changed the docs for
       staticmethod and classmethod in the library
       manual to use decorator syntax (with a pointer
       to the decorator description in the
       reference manual).

     - Added more tests to test_decorator.py,
       including some possibly useful example
       decorators (e.g. memoize)

Other changes (not directly related to decorators):
           
     - I regenerated Lib/compiler/ast.py using
       Tools/compiler/astgen.py.  I'm not sure
       whether astgen.py is still in use -- I had
       to tweak it a bit to make the output match
       ast.py.  I changed astgen.py to emit the
       classes in alphabetical rather than dict
       scan order to make it easier to diff the
       output against ast.py

     - test_pyclbr.py had a broken definition of
       assertEquals - it always returned True if
       called with two arguments.  I renamed this
       to assertEqualsOrIgnored and fixed the bug.
       The working test revealed a test failure in
       pyclbr.py:

     - Changed pyclbr to use the full (dotted)
       module name for pyclbr.Class.module attribute
       
Issues:

     - test_pyclbr.py currently fails because its
       is_method() method fails to spot staticmethod-
       and classmethod- wrapped methods.  See the
       comment on the new test test_decorators().
       I'll have another look at this next week.
       Note that this is a problem with the test,
       not the pyclbr.py module.  For now
       test_decorator could just be deleted.

----------------------------------------------------------------------

Comment By: Mark Russell (mark_t_russell)
Date: 2004-07-28 17:37

Message:
Logged In: YES 
user_id=1017234

I've added an updated version of the patch, with the
following changes:

     - Applied against CVS head (as of 2004-07-28)
     - Non-standard C removed (see Guido's comment)
     - Newline before the def is now mandatory
     - Grammer for decorator expressions more restricted
     - tokenize.py and test_tokenize updated to handle @ tokens
     - Lib/compiler/transformer.py minimally updated

Still to do:

     - Complete work on Lib/compiler (i.e. get it to the
point where it
       produces a correct .pyc for code with decorators).
     - Write docs
     - Work through all the steps in PEP 306
     - Add more regression tests to test_decorator

I can put in some time on this in the next few days if this
patch seems likely
to be applied.

The grammar is now:

     decorator: '@' dotted_name [ '(' [arglist] ')' ]
     decorators: decorator ([NEWLINE] decorator)* NEWLINE
     funcdef: [decorators] 'def' NAME parameters ':' suite

This allows

     @foo @bar
     def f(): pass

but not:

     @foo @bar def f(): paqss

Issues:

    - Someone should take a look at the "case decorator:"
code in
      symtable_node() in compile.c.  All the tests pass, but
this
      seems a fragile bit of code to be changing

    - Lib/compiler needs some more work - at present
decorators are
      ignored there.  I'll do some more work on this when I
get time
      (probably this weekend).

    - As noted in the comments here, the build system does
not cope
      automatically with grammar changes.  The steps I used
to apply
      the patch are:

	   cd .../dist/src
           patch -p0 < /path/to/patch-file
	   ./configure
	   make
	   chmod +w Lib/symbol.py Lib/token.py
	   ./python Lib/symbol.py
	   ./python Lib/token.py
	   make clean
	   make
	   make test >& make-test.out

       I'm sure this sequence is non-optimal, but it works
for me, and
       all the tests pass on my Linux system afterwards.	   


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-28 03:39

Message:
Logged In: YES 
user_id=6380

There's some non-standard C: in compile.c line 5641 there's a 
char* declaration that isn't at the start of a block. Easily 
fixed but should definitely be fixed before releasing a2.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-28 03:22

Message:
Logged In: YES 
user_id=6380

Before 2.4final I'd like to see some changes to the syntax:

- Instead of @test, it should be somewhat more restricted, 
preferably @ followed by a dotted name followed by an 
optional argument list. @1+2 or @[1,2,3] just doesn't make 
sense IMO.

- I'd like there to always be a newline between the last 
decorator and the 'def' keyword. (This in the sake 
of "greppability" per python-dev discussion.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-26 14:20

Message:
Logged In: YES 
user_id=6656

Well, PEP 306 is the reference for this sort of thing: also
needed (before 2.4 final) are changes to Lib/compiler and
tokenize.py.  Mark, are you willing/able to work on these?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 14:09

Message:
Logged In: YES 
user_id=29957

Argh. Our Makefile's ability to Do The Right Thing... is not
good. Rebuilding Lib/symbol.py and Lib/token.py makes this
better. The setup.py really should do this automatically.

So - all tests pass. As far as I can see, things still to be
done for this to be in a2:

- Documentation (can wait until a3, I guess)
- More coverage in test_decorator (ditto)



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 13:58

Message:
Logged In: YES 
user_id=29957

I still get a failure in test_transformer after a make
distclean and rebuild and make distclean and rebuild.

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 37, in ?
    test_main()
  File "Lib/test/test_transformer.py", line 32, in test_main
    test_support.run_unittest(
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
    run_suite(suite, testclass)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_transformer.py", line 16, in
testMultipleLHS
    a = transformer.parse(s)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 113, in transform
    return self.compile_node(tree)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 149, in compile_node
    return self.file_input(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 180, in file_input
    self.com_append_stmt(stmts, node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1025, in com_append_stmt
    result = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 252, in stmt
    return self.com_stmt(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 1018, in com_stmt
    result = self.lookup_node(node)(node[1:])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 312, in expr_stmt
    lval = self.com_augassign(nodelist[0])
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 922, in com_augassign
    l = self.com_node(node)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py",
line 768, in com_node
    return self._dispatch[node[0]](node[1:])
KeyError: 268


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 13:41

Message:
Logged In: YES 
user_id=29957

Hm. Pilot error on my part. I had to build once to get
graminit.h and graminit.c rebuilt, then rebuild again (after
nuking all .o files) to get it to work properly. *sigh*


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-26 13:30

Message:
Logged In: YES 
user_id=29957

After applying this patch, any attempts to use the
newly-built python (I deleted graminit.c and graminit.h, to
make sure they were rebuilt) gives the following on any
'import':

*-s*)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py -q build;; *)  CC='gcc -pthread' LDSHARED='gcc -pthread -shared'
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E
./setup.py build;; esac
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt, imp, re
SystemError: compile_node: unexpected node type
make: *** [sharedmods] Error 1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470