From noreply at sourceforge.net Mon Oct 2 06:04:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Oct 2006 21:04:17 -0700 Subject: [Patches] [ python-Patches-1569040 ] Speed up using + for string concatenation Message-ID: Patches item #1569040, was opened at 2006-10-02 04: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=1569040&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up using + for string concatenation Initial Comment: The core concept: adding two strings together no longer returns a pure "string" object. Instead, it returns a "string concatenation" object which holds references to the two strings but does not actually concatenate them... yet. The strings are concatenated only when someone requests the string's value, at which point it allocates all the space it needs and renders the concatenated string all at once. More to the point, if you add multiple strings together (a + b + c), it *doesn't* compute the intermediate strings (a + b). Upsides to this approach: * String concatenation using + is now the fastest way to concatenate strings (that I know of). * In particular, prepending is *way* faster than it used to be. It used to be a pathological case, n! or something. Now it's linear. * Throw off the shackles of "".join([]), you don't need it anymore. * Did I mention it was faster? Downsides to this approach: * Changes how PyStringObjects are stored internally; ob_sval is no longer a char[1], but a char *. This makes each StringObject four bytes larger. * Adds another memory dereference in order to get the value of a string, which is a teensy-weensy slowdown. * Would force a recompile of all C modules that deal directly with string objects (which I imagine is most of them). * Also, *requires* that C modules use the PyString_AS_STRING() macro, rather than casting the object and grabbing ob_sval directly. (I was pleased to see that the Python source was very good about using this macro; if all Python C modules are this well-behaved, this point is happily moot.) * On a related note, the file Mac/Modules/MacOS.c implies that there are Mac-specific Python scripts that peer directly into string objects. These would have to be changed to understand the new semantics. * String concatenation objects are 36 bytes larger than string objects, and this space will often go unreclaimed after the string is rendered. * When rendered, string concatenation objects storing long strings will allocate a second buffer from the heap to store the string. So this adds some minor allocation overhead (though this is offset by the speed gain from the approach overall). * Will definitely need some heavy review before it could go in, in particular I worry I got the semantics surrounding "interned" strings wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569040&group_id=5470 From noreply at sourceforge.net Mon Oct 2 15:30:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Oct 2006 06:30:28 -0700 Subject: [Patches] [ python-Patches-1569291 ] Speed-up in array_repeat() Message-ID: Patches item #1569291, was opened at 2006-10-02 15:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Skovlund (lskovlund) Assigned to: Nobody/Anonymous (nobody) Summary: Speed-up in array_repeat() Initial Comment: Use iterative doubling when extending the old array. This results in O(log n) calls to memcpy() instead of O(n). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 From noreply at sourceforge.net Tue Oct 3 10:24:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Oct 2006 01:24:36 -0700 Subject: [Patches] [ python-Patches-1569798 ] Fix building the source within exec_prefix Message-ID: Patches item #1569798, was opened at 2006-10-03 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=1569798&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Fix building the source within exec_prefix Initial Comment: [forwarded from http://bugs.debian.org/385336] when built under a subdirectory of exec_prefix, the build fails building the extensions. bug submitter writes: OK, after a debugging session, I found out why. It seems to be an upstream bug in distutils. See python2.5-2.5~c1/Lib/distutils/command/build_ext.py line 188+: if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') This code is executed only in the shared build. The if clause is here to determine whether we're running a correctly installed python or whether we're running python from its source tree. In our case (since we're building python itself atm), the condition *must* evaluate to false. However, this exact check looks very clumsy. On my build system, sys.executable == '/usr/src/debian/build/python2.5-2.5~c1/build-shared/python', sys.exec_prefix == '/usr', i.e. the condition is true and distutils thinks it's running on an already installed python distribution. The reason is that I'm building below the 'install prefix' directory (in /usr/src/...). In contrast, on the Debian buildd machines, this is performed in /build/buildd/.... which does not trigger the distutils bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569798&group_id=5470 From noreply at sourceforge.net Tue Oct 3 19:22:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Oct 2006 10:22:50 -0700 Subject: [Patches] [ python-Patches-1570119 ] distutils - python 2.5 vc8 - non working setup Message-ID: Patches item #1570119, was opened at 2006-10-03 19:22 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=1570119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: distutils - python 2.5 vc8 - non working setup Initial Comment: msvc prior to 8.0 have used .net sdk 1.1 as topelevel version (7.0 - 1.0, 1.1 - 1.1 sp3) - msvc 8.0 uses 2.0 - this mall change makes it's still usefull - wxwidgets goes without problems ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 From noreply at sourceforge.net Tue Oct 3 22:34:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Oct 2006 13:34:48 -0700 Subject: [Patches] [ python-Patches-1570253 ] Fix for compilation errors in the 2.4 branch Message-ID: Patches item #1570253, was opened at 2006-10-03 22: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=1570253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for compilation errors in the 2.4 branch Initial Comment: Revision 52017 introduced some changes to the msvcrt and winsound modules that broke the compilation on windows. See the buildbot logs for details. This error occurs only in the release24-maint branch. This is basically just a backport of revisions r42095 and r42096. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570253&group_id=5470 From noreply at sourceforge.net Wed Oct 4 02:10:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Oct 2006 17:10:16 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 19:02 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Tony Nelson (tony_nelson) Assigned to: Neal Norwitz (nnorwitz) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Tony Nelson (tony_nelson) Date: 2006-10-03 20:10 Message: Logged In: YES user_id=1356214 Here is a version of the patch for the 2.4.4 maintenance branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-02 02:48 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51039. (2.5) ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 17:56 Message: Logged In: YES user_id=1356214 I'm pretty sure that the bug would affect MSWindows. I don't know how to make the test work without sending a signal, such as signal.alarm() or os.kill(), which don't seem to be available on other platforms. I've marked the test with XXX and a comment as requested. I've posed the question on python-dev. Should I ask there for specific help writing the test? The test in this version of the patch has fewer race conditions (and reports the bug differently) than the previous test. The functional part of the patch is unchanged. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 14:23 Message: Logged In: YES user_id=33168 Does the bug affect Windows? A test that only runs on Unix is better than nothing. If the test can't be fixed to run on Windows, please add a comment with an XXX to discuss this and try to get someone to impl a Windows version. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 10:36 Message: Logged In: YES user_id=1356214 Darn. My test will only work on *nix, and not on other platforms such as MSWindows. I don't see a way to send a signal that would work on all platforms, so I don't know a way to test the patch. I'll have to ask for help. The test may need to be changed to only test on *nix. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 23:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 23:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 21:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 14:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Wed Oct 4 06:56:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Oct 2006 21:56:16 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 16:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Tony Nelson (tony_nelson) >Assigned to: A.M. Kuchling (akuchling) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-03 21:56 Message: Logged In: YES user_id=33168 Assigning to Andrew if he's interested in backporting. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-10-03 17:10 Message: Logged In: YES user_id=1356214 Here is a version of the patch for the 2.4.4 maintenance branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-01 23:48 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51039. (2.5) ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 14:56 Message: Logged In: YES user_id=1356214 I'm pretty sure that the bug would affect MSWindows. I don't know how to make the test work without sending a signal, such as signal.alarm() or os.kill(), which don't seem to be available on other platforms. I've marked the test with XXX and a comment as requested. I've posed the question on python-dev. Should I ask there for specific help writing the test? The test in this version of the patch has fewer race conditions (and reports the bug differently) than the previous test. The functional part of the patch is unchanged. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 11:23 Message: Logged In: YES user_id=33168 Does the bug affect Windows? A test that only runs on Unix is better than nothing. If the test can't be fixed to run on Windows, please add a comment with an XXX to discuss this and try to get someone to impl a Windows version. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 07:36 Message: Logged In: YES user_id=1356214 Darn. My test will only work on *nix, and not on other platforms such as MSWindows. I don't see a way to send a signal that would work on all platforms, so I don't know a way to test the patch. I'll have to ask for help. The test may need to be changed to only test on *nix. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 20:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 18:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Wed Oct 4 08:20:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Oct 2006 23:20:29 -0700 Subject: [Patches] [ python-Patches-1570119 ] distutils - python 2.5 vc8 - non working setup Message-ID: Patches item #1570119, was opened at 2006-10-03 19:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: distutils - python 2.5 vc8 - non working setup Initial Comment: msvc prior to 8.0 have used .net sdk 1.1 as topelevel version (7.0 - 1.0, 1.1 - 1.1 sp3) - msvc 8.0 uses 2.0 - this mall change makes it's still usefull - wxwidgets goes without problems ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-04 08:20 Message: Logged In: YES user_id=21627 This patch is wrong. It should use these macros only if get_build_version returns a version >=8.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 From noreply at sourceforge.net Wed Oct 4 09:41:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Oct 2006 00:41:30 -0700 Subject: [Patches] [ python-Patches-1570119 ] distutils - python 2.5 vc8 - non working setup Message-ID: Patches item #1570119, was opened at 2006-10-03 19:22 Message generated for change (Comment added) made by makaron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: distutils - python 2.5 vc8 - non working setup Initial Comment: msvc prior to 8.0 have used .net sdk 1.1 as topelevel version (7.0 - 1.0, 1.1 - 1.1 sp3) - msvc 8.0 uses 2.0 - this mall change makes it's still usefull - wxwidgets goes without problems ---------------------------------------------------------------------- >Comment By: Grzegorz Makarewicz (makaron) Date: 2006-10-04 09:41 Message: Logged In: YES user_id=115179 C:\>python Python 2.5 (release25-maint, Sep 21 2006, 10:06:38) [MSC v.1400 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. I have recompiled python with visual studio 2005 - so it's a msvc 8.0 and get_build_version returns 8.0 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-04 08:20 Message: Logged In: YES user_id=21627 This patch is wrong. It should use these macros only if get_build_version returns a version >=8.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 From noreply at sourceforge.net Wed Oct 4 11:15:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Oct 2006 02:15:47 -0700 Subject: [Patches] [ python-Patches-1570253 ] Fix for compilation errors in the 2.4 branch Message-ID: Patches item #1570253, was opened at 2006-10-03 22:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for compilation errors in the 2.4 branch Initial Comment: Revision 52017 introduced some changes to the msvcrt and winsound modules that broke the compilation on windows. See the buildbot logs for details. This error occurs only in the release24-maint branch. This is basically just a backport of revisions r42095 and r42096. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-10-04 11:15 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52133. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570253&group_id=5470 From noreply at sourceforge.net Wed Oct 4 15:05:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Oct 2006 06:05:36 -0700 Subject: [Patches] [ python-Patches-1570672 ] qtsupport.py mistake leads to bad _Qt module Message-ID: Patches item #1570672, was opened at 2006-10-04 09:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570672&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Senn (senn) Assigned to: Jack Jansen (jackjansen) Summary: qtsupport.py mistake leads to bad _Qt module Initial Comment: All current instances of CmpObj in qtsupport.py except the first need to be CmpInstObj instead. All of those types are actually ComponentInstance not Component. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570672&group_id=5470 From noreply at sourceforge.net Wed Oct 4 21:12:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Oct 2006 12:12:57 -0700 Subject: [Patches] [ python-Patches-1570119 ] distutils - python 2.5 vc8 - non working setup Message-ID: Patches item #1570119, was opened at 2006-10-03 19:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: distutils - python 2.5 vc8 - non working setup Initial Comment: msvc prior to 8.0 have used .net sdk 1.1 as topelevel version (7.0 - 1.0, 1.1 - 1.1 sp3) - msvc 8.0 uses 2.0 - this mall change makes it's still usefull - wxwidgets goes without problems ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-04 21:12 Message: Logged In: YES user_id=21627 Sure - that patch makes it work with VC8. However, it breaks it for VC 7.1. That is not acceptable. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2006-10-04 09:41 Message: Logged In: YES user_id=115179 C:\>python Python 2.5 (release25-maint, Sep 21 2006, 10:06:38) [MSC v.1400 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. I have recompiled python with visual studio 2005 - so it's a msvc 8.0 and get_build_version returns 8.0 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-04 08:20 Message: Logged In: YES user_id=21627 This patch is wrong. It should use these macros only if get_build_version returns a version >=8.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1570119&group_id=5470 From noreply at sourceforge.net Thu Oct 5 09:57:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Oct 2006 00:57:32 -0700 Subject: [Patches] [ python-Patches-1571184 ] Generate numeric/space/linebreak from Unicode database. Message-ID: Patches item #1571184, was opened at 2006-10-05 09: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=1571184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anders Chrigstr?m (andersch) Assigned to: Nobody/Anonymous (nobody) Summary: Generate numeric/space/linebreak from Unicode database. Initial Comment: This patch changes the functions _PyUnicode_ToNumeric, _PyUnicode_IsLinebreak and _PyUnicode_IsWhitespace from having to be manually updated into being generated from data in the unicode database. It will allso read numeric values for characters whos numeric type is defined in the Unihan.txt file and not in the UnicodeData.txt file. The patch should work for both the release25-maint branch as well as the trunk. The patch is so big i had to split it into two files for sourcefore to accept it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571184&group_id=5470 From noreply at sourceforge.net Thu Oct 5 12:45:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Oct 2006 03:45:25 -0700 Subject: [Patches] [ python-Patches-1571184 ] Generate numeric/space/linebreak from Unicode database. Message-ID: Patches item #1571184, was opened at 2006-10-05 09:57 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anders Chrigstr?m (andersch) Assigned to: Nobody/Anonymous (nobody) Summary: Generate numeric/space/linebreak from Unicode database. Initial Comment: This patch changes the functions _PyUnicode_ToNumeric, _PyUnicode_IsLinebreak and _PyUnicode_IsWhitespace from having to be manually updated into being generated from data in the unicode database. It will allso read numeric values for characters whos numeric type is defined in the Unihan.txt file and not in the UnicodeData.txt file. The patch should work for both the release25-maint branch as well as the trunk. The patch is so big i had to split it into two files for sourcefore to accept it. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-10-05 12:45 Message: Logged In: YES user_id=38388 Instead of attaching the patch with the generated code, could you please just attach the script that generates the files and/or any patch needed to support the new generation of the above three functions ? That makes reviewing this a lot easier. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571184&group_id=5470 From noreply at sourceforge.net Thu Oct 5 15:10:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Oct 2006 06:10:15 -0700 Subject: [Patches] [ python-Patches-1571379 ] make trace.py --ignore-dir work Message-ID: Patches item #1571379, was opened at 2006-10-05 13: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=1571379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Clinton Roy (clintonroy) Assigned to: Nobody/Anonymous (nobody) Summary: make trace.py --ignore-dir work Initial Comment: The co_filename attribute is only ever the relative filename, where as the __file__ value of the frame globals is absolute, which lets the ignore() stuff do its thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571379&group_id=5470 From noreply at sourceforge.net Fri Oct 6 11:44:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Oct 2006 02:44:40 -0700 Subject: [Patches] [ python-Patches-1571184 ] Generate numeric/space/linebreak from Unicode database. Message-ID: Patches item #1571184, was opened at 2006-10-05 09:57 Message generated for change (Comment added) made by andersch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anders Chrigstr?m (andersch) Assigned to: Nobody/Anonymous (nobody) Summary: Generate numeric/space/linebreak from Unicode database. Initial Comment: This patch changes the functions _PyUnicode_ToNumeric, _PyUnicode_IsLinebreak and _PyUnicode_IsWhitespace from having to be manually updated into being generated from data in the unicode database. It will allso read numeric values for characters whos numeric type is defined in the Unihan.txt file and not in the UnicodeData.txt file. The patch should work for both the release25-maint branch as well as the trunk. The patch is so big i had to split it into two files for sourcefore to accept it. ---------------------------------------------------------------------- >Comment By: Anders Chrigstr?m (andersch) Date: 2006-10-06 11:44 Message: Logged In: YES user_id=621306 Here is a patch without the generated files. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-10-05 12:45 Message: Logged In: YES user_id=38388 Instead of attaching the patch with the generated code, could you please just attach the script that generates the files and/or any patch needed to support the new generation of the above three functions ? That makes reviewing this a lot easier. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571184&group_id=5470 From noreply at sourceforge.net Sat Oct 7 12:25:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 03:25:48 -0700 Subject: [Patches] [ python-Patches-1571379 ] make trace.py --ignore-dir work Message-ID: Patches item #1571379, was opened at 2006-10-05 08:10 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Clinton Roy (clintonroy) >Assigned to: Skip Montanaro (montanaro) Summary: make trace.py --ignore-dir work Initial Comment: The co_filename attribute is only ever the relative filename, where as the __file__ value of the frame globals is absolute, which lets the ignore() stuff do its thing. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-10-07 05:25 Message: Logged In: YES user_id=44345 Without digging too deeply, can you explain why only this one instance of using code.co_filename needs to be changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571379&group_id=5470 From noreply at sourceforge.net Sat Oct 7 15:17:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 06:17:13 -0700 Subject: [Patches] [ python-Patches-1572724 ] typo in PC/_msi.c Message-ID: Patches item #1572724, was opened at 2006-10-07 09: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=1572724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jose nazario (jnazario) Assigned to: Nobody/Anonymous (nobody) Summary: typo in PC/_msi.c Initial Comment: basic typo in PC/_msi.c, assignment vs comparison (fat fingered?) not sure of the implications, but it looks like more of a relibility fix than anything. --- PC/_msi.c.orig Sat Oct 7 09:12:46 2006 +++ PC/_msi.c Sat Oct 7 09:12:59 2006 @@ -495,7 +495,7 @@ status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); - if (status = ERROR_MORE_DATA) { + if (status == ERROR_MORE_DATA) { sval = malloc(ssize); status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 From noreply at sourceforge.net Sat Oct 7 15:18:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 06:18:00 -0700 Subject: [Patches] [ python-Patches-1572724 ] typo in PC/_msi.c Message-ID: Patches item #1572724, was opened at 2006-10-07 09:17 Message generated for change (Comment added) made by jnazario You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jose nazario (jnazario) Assigned to: Nobody/Anonymous (nobody) Summary: typo in PC/_msi.c Initial Comment: basic typo in PC/_msi.c, assignment vs comparison (fat fingered?) not sure of the implications, but it looks like more of a relibility fix than anything. --- PC/_msi.c.orig Sat Oct 7 09:12:46 2006 +++ PC/_msi.c Sat Oct 7 09:12:59 2006 @@ -495,7 +495,7 @@ status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); - if (status = ERROR_MORE_DATA) { + if (status == ERROR_MORE_DATA) { sval = malloc(ssize); status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); ---------------------------------------------------------------------- >Comment By: jose nazario (jnazario) Date: 2006-10-07 09:17 Message: Logged In: YES user_id=350099 PS: verified this is also present in the latest SVN repository. http://svn.python.org/view/python/trunk/PC/_msi.c?rev=42848&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 From noreply at sourceforge.net Sat Oct 7 15:22:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 06:22:16 -0700 Subject: [Patches] [ python-Patches-1572724 ] typo in PC/_msi.c Message-ID: Patches item #1572724, was opened at 2006-10-07 13:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jose nazario (jnazario) >Assigned to: Martin v. L?wis (loewis) Summary: typo in PC/_msi.c Initial Comment: basic typo in PC/_msi.c, assignment vs comparison (fat fingered?) not sure of the implications, but it looks like more of a relibility fix than anything. --- PC/_msi.c.orig Sat Oct 7 09:12:46 2006 +++ PC/_msi.c Sat Oct 7 09:12:59 2006 @@ -495,7 +495,7 @@ status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); - if (status = ERROR_MORE_DATA) { + if (status == ERROR_MORE_DATA) { sval = malloc(ssize); status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-07 13:22 Message: Logged In: YES user_id=849994 Assigning to Martin. ---------------------------------------------------------------------- Comment By: jose nazario (jnazario) Date: 2006-10-07 13:17 Message: Logged In: YES user_id=350099 PS: verified this is also present in the latest SVN repository. http://svn.python.org/view/python/trunk/PC/_msi.c?rev=42848&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 From noreply at sourceforge.net Sat Oct 7 18:39:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 09:39:05 -0700 Subject: [Patches] [ python-Patches-1569291 ] Speed-up in array_repeat() Message-ID: Patches item #1569291, was opened at 2006-10-02 06:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Skovlund (lskovlund) Assigned to: Nobody/Anonymous (nobody) Summary: Speed-up in array_repeat() Initial Comment: Use iterative doubling when extending the old array. This results in O(log n) calls to memcpy() instead of O(n). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 09:39 Message: Logged In: YES user_id=341410 Have you benchmarked this for repeats found "in the wild" to establish *observable* speedup for code that already exists? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 From noreply at sourceforge.net Sat Oct 7 19:00:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 10:00:17 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 21:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Simon Law (sfllaw) Assigned to: Neal Norwitz (nnorwitz) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-07 17:00 Message: Logged In: YES user_id=849994 Attaching a code file containing a Python version of the Unicode string escape routine for UCS-4 builds. (it only replaces repr() if called from python, so not everything is fixed, esp. "%r") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 08:26 Message: Logged In: YES user_id=849994 Applied to 2.4 in revision 51466. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 22:22 Message: Logged In: YES user_id=33168 Committed revision 51448. (2.6) Committed revision 51450. (2.5) Someone should backport to 2.4, leaving open until then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Sat Oct 7 20:00:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 11:00:20 -0700 Subject: [Patches] [ python-Patches-1572832 ] Fix for segfault in ISO 2022 codecs Message-ID: Patches item #1572832, was opened at 2006-10-07 14: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=1572832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ray Chason (chasonr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for segfault in ISO 2022 codecs Initial Comment: This may relate to bug report 1005078, which was closed because it couldn't be duplicated with the information given. Run the following program for a segmentation fault on your Python interpreter: --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- import sys for x in xrange(0x10000, 0x110000): if sys.maxunicode >= 0x10000: ch = unichr(x) else: ch = unichr(0xD7C0+(x>>10)) + unichr(0xDC00+(x & 0x3FF)) try: # Any ISO 2022 codec will cause the segfault ch.encode("iso_2022_jp") except UnicodeEncodeError: pass --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- I have verified this bug on four different Pythons: * The current ActivePython (2.4.3 based), running on Windows XP SP2 * The stock Python 2.4.2 on Ubuntu Breezy (i386) * The stock Python 2.4.2 on Ubuntu Breezy (AMD64) * A home-built Python 2.5 on Ubuntu Breezy (i386); --enable-unicode=ucs4 is selected and other options are left at default It does not just affect iso_2022_jp, but all of the ISO 2002 codecs. If you are attempting to replicate the bug on Linux, you may get more repeatble results if you first go root and then: echo 0 > /proc/sys/kernel/randomize_va_space This seems related to bug report 1005078. However, bug report 1005078 claimed that a character in the BMP could cause a crash. I have not reproduced that bug using a BMP character; however, supplementary characters can in fact cause the ISO 2022 codecs to crash. The problem is that four functions in Modules/cjkcodecs/_codecs_iso2022.c do not check that the code point is less than 0x10000 before invoking the TRYMAP_ENC macro. This causes the bounds of the encoding table to be exceeded. The four functions are: * ksx1001_encoder * jisx0208_encoder * jisx0212_encoder * gb2312_encoder The enclosed patch adds the necessary checks, and the above program then completes without incident. It is derived from the official 2.5 release, but also applies cleanly against the daily drop of 6 October 2006 because the file Modules/cjkcodecs/_codecs_iso2022.c is unchanged in that drop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572832&group_id=5470 From noreply at sourceforge.net Sat Oct 7 20:07:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 11:07:58 -0700 Subject: [Patches] [ python-Patches-1572832 ] Fix for segfault in ISO 2022 codecs Message-ID: Patches item #1572832, was opened at 2006-10-07 14:00 Message generated for change (Comment added) made by chasonr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ray Chason (chasonr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for segfault in ISO 2022 codecs Initial Comment: This may relate to bug report 1005078, which was closed because it couldn't be duplicated with the information given. Run the following program for a segmentation fault on your Python interpreter: --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- import sys for x in xrange(0x10000, 0x110000): if sys.maxunicode >= 0x10000: ch = unichr(x) else: ch = unichr(0xD7C0+(x>>10)) + unichr(0xDC00+(x & 0x3FF)) try: # Any ISO 2022 codec will cause the segfault ch.encode("iso_2022_jp") except UnicodeEncodeError: pass --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- I have verified this bug on four different Pythons: * The current ActivePython (2.4.3 based), running on Windows XP SP2 * The stock Python 2.4.2 on Ubuntu Breezy (i386) * The stock Python 2.4.2 on Ubuntu Breezy (AMD64) * A home-built Python 2.5 on Ubuntu Breezy (i386); --enable-unicode=ucs4 is selected and other options are left at default It does not just affect iso_2022_jp, but all of the ISO 2002 codecs. If you are attempting to replicate the bug on Linux, you may get more repeatble results if you first go root and then: echo 0 > /proc/sys/kernel/randomize_va_space This seems related to bug report 1005078. However, bug report 1005078 claimed that a character in the BMP could cause a crash. I have not reproduced that bug using a BMP character; however, supplementary characters can in fact cause the ISO 2022 codecs to crash. The problem is that four functions in Modules/cjkcodecs/_codecs_iso2022.c do not check that the code point is less than 0x10000 before invoking the TRYMAP_ENC macro. This causes the bounds of the encoding table to be exceeded. The four functions are: * ksx1001_encoder * jisx0208_encoder * jisx0212_encoder * gb2312_encoder The enclosed patch adds the necessary checks, and the above program then completes without incident. It is derived from the official 2.5 release, but also applies cleanly against the daily drop of 6 October 2006 because the file Modules/cjkcodecs/_codecs_iso2022.c is unchanged in that drop. ---------------------------------------------------------------------- >Comment By: Ray Chason (chasonr) Date: 2006-10-07 14:07 Message: Logged In: YES user_id=421946 The upload seems to have quietly failed to work. Also, the indents got mashed on that test program, and we all know how important indents are to Python. Here it is again, with the test program prefixed this time. ---------------------------------------------------------------------- Comment By: Ray Chason (chasonr) Date: 2006-10-07 14:07 Message: Logged In: YES user_id=421946 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=1572832&group_id=5470 From noreply at sourceforge.net Sun Oct 8 00:12:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 15:12:38 -0700 Subject: [Patches] [ python-Patches-1569291 ] Speed-up in array_repeat() Message-ID: Patches item #1569291, was opened at 2006-10-02 15:30 Message generated for change (Comment added) made by lskovlund You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Skovlund (lskovlund) Assigned to: Nobody/Anonymous (nobody) Summary: Speed-up in array_repeat() Initial Comment: Use iterative doubling when extending the old array. This results in O(log n) calls to memcpy() instead of O(n). ---------------------------------------------------------------------- >Comment By: Lars Skovlund (lskovlund) Date: 2006-10-08 00:12 Message: Logged In: YES user_id=263372 I wrote this code for a university project I'm doing myself, which involves initializing a *very* large array (it's a remote memory system). It does help there, certainly; for medium-sized arrays, the improvement would be negligable, and for small ones it might even be worse. If you mean, have I benchmarked it with other people's code, no. I just thought I'd offer it to the community, since it has certainly helped me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 18:39 Message: Logged In: YES user_id=341410 Have you benchmarked this for repeats found "in the wild" to establish *observable* speedup for code that already exists? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 From noreply at sourceforge.net Sun Oct 8 00:43:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 15:43:23 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 23:27 Message generated for change (Comment added) made by alexanderweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Simon Law (sfllaw) Assigned to: Neal Norwitz (nnorwitz) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- Comment By: Alexander Schremmer (alexanderweb) Date: 2006-10-08 00:43 Message: Logged In: YES user_id=254738 The CVE issue for this bug is CVE-2006-4980, which currently still under review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-07 19:00 Message: Logged In: YES user_id=849994 Attaching a code file containing a Python version of the Unicode string escape routine for UCS-4 builds. (it only replaces repr() if called from python, so not everything is fixed, esp. "%r") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 10:26 Message: Logged In: YES user_id=849994 Applied to 2.4 in revision 51466. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 00:22 Message: Logged In: YES user_id=33168 Committed revision 51448. (2.6) Committed revision 51450. (2.5) Someone should backport to 2.4, leaving open until then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Sun Oct 8 02:49:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 17:49:33 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 00:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-07 17:49 Message: Logged In: YES user_id=33168 Georg, if you don't mind doing this, I think it's fine to go into 2.5.1. I'll try to get around to it at some point if not. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 01:48 Message: Logged In: YES user_id=849994 Time to checkin for 2.5.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 12:48 Message: Logged In: YES user_id=33168 Committed revision 51439. (2.6) Thomas Wouters thinks this is fine to go in 2.5. I'll leave open for now until we decide what to do. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-21 12:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 08:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 01:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Sun Oct 8 02:53:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 17:53:50 -0700 Subject: [Patches] [ python-Patches-1572832 ] Fix for segfault in ISO 2022 codecs Message-ID: Patches item #1572832, was opened at 2006-10-07 11:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ray Chason (chasonr) >Assigned to: Hye-Shik Chang (perky) Summary: Fix for segfault in ISO 2022 codecs Initial Comment: This may relate to bug report 1005078, which was closed because it couldn't be duplicated with the information given. Run the following program for a segmentation fault on your Python interpreter: --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- import sys for x in xrange(0x10000, 0x110000): if sys.maxunicode >= 0x10000: ch = unichr(x) else: ch = unichr(0xD7C0+(x>>10)) + unichr(0xDC00+(x & 0x3FF)) try: # Any ISO 2022 codec will cause the segfault ch.encode("iso_2022_jp") except UnicodeEncodeError: pass --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- I have verified this bug on four different Pythons: * The current ActivePython (2.4.3 based), running on Windows XP SP2 * The stock Python 2.4.2 on Ubuntu Breezy (i386) * The stock Python 2.4.2 on Ubuntu Breezy (AMD64) * A home-built Python 2.5 on Ubuntu Breezy (i386); --enable-unicode=ucs4 is selected and other options are left at default It does not just affect iso_2022_jp, but all of the ISO 2002 codecs. If you are attempting to replicate the bug on Linux, you may get more repeatble results if you first go root and then: echo 0 > /proc/sys/kernel/randomize_va_space This seems related to bug report 1005078. However, bug report 1005078 claimed that a character in the BMP could cause a crash. I have not reproduced that bug using a BMP character; however, supplementary characters can in fact cause the ISO 2022 codecs to crash. The problem is that four functions in Modules/cjkcodecs/_codecs_iso2022.c do not check that the code point is less than 0x10000 before invoking the TRYMAP_ENC macro. This causes the bounds of the encoding table to be exceeded. The four functions are: * ksx1001_encoder * jisx0208_encoder * jisx0212_encoder * gb2312_encoder The enclosed patch adds the necessary checks, and the above program then completes without incident. It is derived from the official 2.5 release, but also applies cleanly against the daily drop of 6 October 2006 because the file Modules/cjkcodecs/_codecs_iso2022.c is unchanged in that drop. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-07 17:53 Message: Logged In: YES user_id=33168 Thanks for the report. Perky, could you take a look at this patch? I don't know if it's correct or not. ---------------------------------------------------------------------- Comment By: Ray Chason (chasonr) Date: 2006-10-07 11:07 Message: Logged In: YES user_id=421946 The upload seems to have quietly failed to work. Also, the indents got mashed on that test program, and we all know how important indents are to Python. Here it is again, with the test program prefixed this time. ---------------------------------------------------------------------- Comment By: Ray Chason (chasonr) Date: 2006-10-07 11:07 Message: Logged In: YES user_id=421946 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=1572832&group_id=5470 From noreply at sourceforge.net Sun Oct 8 02:59:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Oct 2006 17:59:44 -0700 Subject: [Patches] [ python-Patches-1569291 ] Speed-up in array_repeat() Message-ID: Patches item #1569291, was opened at 2006-10-02 08:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Lars Skovlund (lskovlund) >Assigned to: Raymond Hettinger (rhettinger) Summary: Speed-up in array_repeat() Initial Comment: Use iterative doubling when extending the old array. This results in O(log n) calls to memcpy() instead of O(n). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-07 19:59 Message: Logged In: YES user_id=80475 This patch is basically fine. Will neaten it up to match our source coding conventions and apply it when I get a chance. Py2.6 won't be out for a good while, so there is no hurry. ---------------------------------------------------------------------- Comment By: Lars Skovlund (lskovlund) Date: 2006-10-07 17:12 Message: Logged In: YES user_id=263372 I wrote this code for a university project I'm doing myself, which involves initializing a *very* large array (it's a remote memory system). It does help there, certainly; for medium-sized arrays, the improvement would be negligable, and for small ones it might even be worse. If you mean, have I benchmarked it with other people's code, no. I just thought I'd offer it to the community, since it has certainly helped me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 11:39 Message: Logged In: YES user_id=341410 Have you benchmarked this for repeats found "in the wild" to establish *observable* speedup for code that already exists? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 From noreply at sourceforge.net Sun Oct 8 09:06:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Oct 2006 00:06:50 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 07:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-08 07:06 Message: Logged In: YES user_id=849994 Committed rev. 52220 in 2.5 branch. Closing now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-08 00:49 Message: Logged In: YES user_id=33168 Georg, if you don't mind doing this, I think it's fine to go into 2.5.1. I'll try to get around to it at some point if not. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:48 Message: Logged In: YES user_id=849994 Time to checkin for 2.5.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 19:48 Message: Logged In: YES user_id=33168 Committed revision 51439. (2.6) Thomas Wouters thinks this is fine to go in 2.5. I'll leave open for now until we decide what to do. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-21 19:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 15:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 08:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Sun Oct 8 14:02:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Oct 2006 05:02:52 -0700 Subject: [Patches] [ python-Patches-1571379 ] make trace.py --ignore-dir work Message-ID: Patches item #1571379, was opened at 2006-10-05 13:10 Message generated for change (Comment added) made by clintonroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Clinton Roy (clintonroy) Assigned to: Skip Montanaro (montanaro) Summary: make trace.py --ignore-dir work Initial Comment: The co_filename attribute is only ever the relative filename, where as the __file__ value of the frame globals is absolute, which lets the ignore() stuff do its thing. ---------------------------------------------------------------------- >Comment By: Clinton Roy (clintonroy) Date: 2006-10-08 12:02 Message: Logged In: YES user_id=31446 Hi Skip, This patch only addresses --ignore-dir working, I didn't initally look at the other uses. Now that I have, they're all passed to linecache, which itself looks in $prefix for a matching filename, so it only needs the relative filename to be passed. My patch specifically just targets the filename param passed to ignore.names() so that it can actually work. cheers, ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-07 10:25 Message: Logged In: YES user_id=44345 Without digging too deeply, can you explain why only this one instance of using code.co_filename needs to be changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1571379&group_id=5470 From noreply at sourceforge.net Sun Oct 8 16:05:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Oct 2006 07:05:24 -0700 Subject: [Patches] [ python-Patches-1572832 ] Fix for segfault in ISO 2022 codecs Message-ID: Patches item #1572832, was opened at 2006-10-08 03:00 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ray Chason (chasonr) Assigned to: Hye-Shik Chang (perky) Summary: Fix for segfault in ISO 2022 codecs Initial Comment: This may relate to bug report 1005078, which was closed because it couldn't be duplicated with the information given. Run the following program for a segmentation fault on your Python interpreter: --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- import sys for x in xrange(0x10000, 0x110000): if sys.maxunicode >= 0x10000: ch = unichr(x) else: ch = unichr(0xD7C0+(x>>10)) + unichr(0xDC00+(x & 0x3FF)) try: # Any ISO 2022 codec will cause the segfault ch.encode("iso_2022_jp") except UnicodeEncodeError: pass --CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE--CUT HERE-- I have verified this bug on four different Pythons: * The current ActivePython (2.4.3 based), running on Windows XP SP2 * The stock Python 2.4.2 on Ubuntu Breezy (i386) * The stock Python 2.4.2 on Ubuntu Breezy (AMD64) * A home-built Python 2.5 on Ubuntu Breezy (i386); --enable-unicode=ucs4 is selected and other options are left at default It does not just affect iso_2022_jp, but all of the ISO 2002 codecs. If you are attempting to replicate the bug on Linux, you may get more repeatble results if you first go root and then: echo 0 > /proc/sys/kernel/randomize_va_space This seems related to bug report 1005078. However, bug report 1005078 claimed that a character in the BMP could cause a crash. I have not reproduced that bug using a BMP character; however, supplementary characters can in fact cause the ISO 2022 codecs to crash. The problem is that four functions in Modules/cjkcodecs/_codecs_iso2022.c do not check that the code point is less than 0x10000 before invoking the TRYMAP_ENC macro. This causes the bounds of the encoding table to be exceeded. The four functions are: * ksx1001_encoder * jisx0208_encoder * jisx0212_encoder * gb2312_encoder The enclosed patch adds the necessary checks, and the above program then completes without incident. It is derived from the official 2.5 release, but also applies cleanly against the daily drop of 6 October 2006 because the file Modules/cjkcodecs/_codecs_iso2022.c is unchanged in that drop. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-10-08 23:05 Message: Logged In: YES user_id=55188 The patch is correct. Thanks for the report! Applied in svn: r52223 for trunk r52224 for 2.4 r52225 for 2.5 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-08 09:53 Message: Logged In: YES user_id=33168 Thanks for the report. Perky, could you take a look at this patch? I don't know if it's correct or not. ---------------------------------------------------------------------- Comment By: Ray Chason (chasonr) Date: 2006-10-08 03:07 Message: Logged In: YES user_id=421946 The upload seems to have quietly failed to work. Also, the indents got mashed on that test program, and we all know how important indents are to Python. Here it is again, with the test program prefixed this time. ---------------------------------------------------------------------- Comment By: Ray Chason (chasonr) Date: 2006-10-08 03:07 Message: Logged In: YES user_id=421946 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=1572832&group_id=5470 From noreply at sourceforge.net Mon Oct 9 17:51:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 08:51:45 -0700 Subject: [Patches] [ python-Patches-1573835 ] let quit and exit really exit Message-ID: Patches item #1573835, was opened at 2006-10-09 17:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1573835&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: let quit and exit really exit Initial Comment: since Python 2.5, quit() and exit() exit the interpreter. This patch lets quit and exit exit the interpreter as well, by letting __repr__ call self(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1573835&group_id=5470 From noreply at sourceforge.net Mon Oct 9 17:55:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 08:55:23 -0700 Subject: [Patches] [ python-Patches-1573835 ] let quit and exit really exit Message-ID: Patches item #1573835, was opened at 2006-10-09 16:51 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1573835&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Michael Hudson (mwh) Summary: let quit and exit really exit Initial Comment: since Python 2.5, quit() and exit() exit the interpreter. This patch lets quit and exit exit the interpreter as well, by letting __repr__ call self(). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-10-09 16:55 Message: Logged In: YES user_id=6656 No no no, consider what this does: >>> import __builtin__ >>> print __builtin__.__dict__ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1573835&group_id=5470 From noreply at sourceforge.net Mon Oct 9 20:31:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 11:31:52 -0700 Subject: [Patches] [ python-Patches-1352731 ] Small upgrades to platform.platform() Message-ID: Patches item #1352731, was opened at 2005-11-10 02:19 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) Assigned to: M.-A. Lemburg (lemburg) Summary: Small upgrades to platform.platform() Initial Comment: This patch updates platform.platform() to recognize some more Linux distributions. In addition, for RedHat-like distributions, will use the contents of the /etc/ to determine distname. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-10-09 20:31 Message: Logged In: YES user_id=38388 Sorry for the late reply. I must have missed the initial SF mail. I've had a look at the patch, but I'm not sure whether it can be accepted: wouldn't it break already recognized RedHat-like platforms ? ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-11-10 02:23 Message: Logged In: YES user_id=493197 assigning to lemberg as suggested in the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 From noreply at sourceforge.net Mon Oct 9 21:03:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 12:03:29 -0700 Subject: [Patches] [ python-Patches-1572724 ] typo in PC/_msi.c Message-ID: Patches item #1572724, was opened at 2006-10-07 13:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: jose nazario (jnazario) >Assigned to: Georg Brandl (gbrandl) Summary: typo in PC/_msi.c Initial Comment: basic typo in PC/_msi.c, assignment vs comparison (fat fingered?) not sure of the implications, but it looks like more of a relibility fix than anything. --- PC/_msi.c.orig Sat Oct 7 09:12:46 2006 +++ PC/_msi.c Sat Oct 7 09:12:59 2006 @@ -495,7 +495,7 @@ status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); - if (status = ERROR_MORE_DATA) { + if (status == ERROR_MORE_DATA) { sval = malloc(ssize); status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-09 19:03 Message: Logged In: YES user_id=849994 Fixed in rev. 52251, 52252 (2.5). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-07 13:22 Message: Logged In: YES user_id=849994 Assigning to Martin. ---------------------------------------------------------------------- Comment By: jose nazario (jnazario) Date: 2006-10-07 13:17 Message: Logged In: YES user_id=350099 PS: verified this is also present in the latest SVN repository. http://svn.python.org/view/python/trunk/PC/_msi.c?rev=42848&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1572724&group_id=5470 From noreply at sourceforge.net Mon Oct 9 23:40:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 14:40:51 -0700 Subject: [Patches] [ python-Patches-1574068 ] urllib2 - Fix line breaks in authorization headers Message-ID: Patches item #1574068, was opened at 2006-10-09 17:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Dial (geekmug) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 - Fix line breaks in authorization headers Initial Comment: urllib2 uses the wrong base64 encode function from the base64 library. This patch corrects that. Original bug report from "The Doctor What" I found a bug in urllib2's handling of basic HTTP authentication. urllib2 uses the base64.encodestring() method to encode the username:password. The problem is that base64.encodestring() adds newlines to wrap the encoded characters at the 76th column. This produces bogus request headers like this: ---------->8---------cut---------8<---------------- GET /some/url HTTP/1.1 Host: some.host Accept-Encoding: identity Authorization: Basic cmVhbGx5bG9uZ3VzZXJuYW1lOmFuZXZlbmxvbmdlcnBhc3N3b3JkdGhhdGdvZXNvbmFuZG9uYW5k b25hbmRvbmFuZG9u User-agent: some-agent ---------->8---------cut---------8<---------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 From noreply at sourceforge.net Tue Oct 10 00:22:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 15:22:42 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-10-10 07:22 Message: Logged In: YES user_id=595483 The new patch that I am uploading fixes the Grammar problem - originally I made mistake not allowing *vararg after keyword only argument. The python compiler package doesn't work now, but everything else should work now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-16 02:13 Message: Logged In: YES user_id=6380 I see. The Grammar should simply make the NAME after the '*' optional. Shouldn't be too hard to fix should it? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 16:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 06:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-12 04:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-08 02:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 14:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Tue Oct 10 00:48:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 15:48:32 -0700 Subject: [Patches] [ python-Patches-1563842 ] platform.py support for IronPython Message-ID: Patches item #1563842, was opened at 2006-09-23 01:59 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.py support for IronPython Initial Comment: The following patch supplies minimal support for IronPython in platform.py - it makes the sys.version parsing not choke and die. There's a bunch of missing information from IronPython's sys.version string, not much that can be done there. Should platform.py grow an 'implementation' option, so it can detect whether it's IronPython, CPython, Jython, or something else? Patch is against svn trunk. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-10-09 22:48 Message: Logged In: YES user_id=4771 Python2.5 has grown a sys.subversion attribute: ('CPython', 'trunk', '51999') The first field is intended to describe the exact implementation of Python. platform.py could return this if it is available. It should also probably try to use sys.version_info instead of, or in addition to, using a regexp on sys.version. One can hope that in the long term the version_info and the subversion attributes should eventually be supported by all Python implementation (PyPy...). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-25 10:30 Message: Logged In: YES user_id=38388 Thanks. I'll install IronPython and see what else needs to be done. I've already added a few fixes to make Jython play nice with platform.py that I'll check in as well. And yes: I'll add a python_implementation() function that returns 'CPython', 'Jython' and 'IronPython' as appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&group_id=5470 From noreply at sourceforge.net Tue Oct 10 01:22:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 16:22:25 -0700 Subject: [Patches] [ python-Patches-1352731 ] Small upgrades to platform.platform() Message-ID: Patches item #1352731, was opened at 2005-11-10 01:19 Message generated for change (Comment added) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) Assigned to: M.-A. Lemburg (lemburg) Summary: Small upgrades to platform.platform() Initial Comment: This patch updates platform.platform() to recognize some more Linux distributions. In addition, for RedHat-like distributions, will use the contents of the /etc/ to determine distname. ---------------------------------------------------------------------- >Comment By: daishi harada (daishiharada) Date: 2006-10-09 23:22 Message: Logged In: YES user_id=493197 Thanks for the response. If by "break" you mean that for redhat-like distros the output of `python platform.py` would no longer necessarily be the same after the patch is applied, yes, that's true. However, that was the primary motivation for the patch - the current platform.py wasn't sufficiently discriminating for my purposes. In particular, the current platform.py ignores the first "field" of the contents of /etc/redhat-release, which I believe for ROCKS was the only portion which was changed from the redhat version on which it was based. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-10-09 18:31 Message: Logged In: YES user_id=38388 Sorry for the late reply. I must have missed the initial SF mail. I've had a look at the patch, but I'm not sure whether it can be accepted: wouldn't it break already recognized RedHat-like platforms ? ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-11-10 01:23 Message: Logged In: YES user_id=493197 assigning to lemberg as suggested in the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 From noreply at sourceforge.net Tue Oct 10 02:13:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 17:13:17 -0700 Subject: [Patches] [ python-Patches-1574068 ] urllib2 - Fix line breaks in authorization headers Message-ID: Patches item #1574068, was opened at 2006-10-09 22:40 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Dial (geekmug) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 - Fix line breaks in authorization headers Initial Comment: urllib2 uses the wrong base64 encode function from the base64 library. This patch corrects that. Original bug report from "The Doctor What" I found a bug in urllib2's handling of basic HTTP authentication. urllib2 uses the base64.encodestring() method to encode the username:password. The problem is that base64.encodestring() adds newlines to wrap the encoded characters at the 76th column. This produces bogus request headers like this: ---------->8---------cut---------8<---------------- GET /some/url HTTP/1.1 Host: some.host Accept-Encoding: identity Authorization: Basic cmVhbGx5bG9uZ3VzZXJuYW1lOmFuZXZlbmxvbmdlcnBhc3N3b3JkdGhhdGdvZXNvbmFuZG9uYW5k b25hbmRvbmFuZG9u User-agent: some-agent ---------->8---------cut---------8<---------------- ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-10-10 01:13 Message: Logged In: YES user_id=261020 urllib should also be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 From noreply at sourceforge.net Tue Oct 10 02:33:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 17:33:12 -0700 Subject: [Patches] [ python-Patches-1574068 ] urllib2 - Fix line breaks in authorization headers Message-ID: Patches item #1574068, was opened at 2006-10-09 17:40 Message generated for change (Comment added) made by geekmug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Dial (geekmug) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 - Fix line breaks in authorization headers Initial Comment: urllib2 uses the wrong base64 encode function from the base64 library. This patch corrects that. Original bug report from "The Doctor What" I found a bug in urllib2's handling of basic HTTP authentication. urllib2 uses the base64.encodestring() method to encode the username:password. The problem is that base64.encodestring() adds newlines to wrap the encoded characters at the 76th column. This produces bogus request headers like this: ---------->8---------cut---------8<---------------- GET /some/url HTTP/1.1 Host: some.host Accept-Encoding: identity Authorization: Basic cmVhbGx5bG9uZ3VzZXJuYW1lOmFuZXZlbmxvbmdlcnBhc3N3b3JkdGhhdGdvZXNvbmFuZG9uYW5k b25hbmRvbmFuZG9u User-agent: some-agent ---------->8---------cut---------8<---------------- ---------------------------------------------------------------------- >Comment By: Scott Dial (geekmug) Date: 2006-10-09 20:33 Message: Logged In: YES user_id=383208 Ah yes, you are correct that urllib has the same problem. I have attached a patch to correct all of those instances as well. It is note-worthy that the one usage of decodestring in urllib is correct (as it is decoding the body of the response and should reasonably expect to see newlines in that encoding). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-10-09 20:13 Message: Logged In: YES user_id=261020 urllib should also be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 From noreply at sourceforge.net Tue Oct 10 04:35:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 19:35:37 -0700 Subject: [Patches] [ python-Patches-1563842 ] platform.py support for IronPython Message-ID: Patches item #1563842, was opened at 2006-09-23 10:59 Message generated for change (Comment added) made by sanxiyn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.py support for IronPython Initial Comment: The following patch supplies minimal support for IronPython in platform.py - it makes the sys.version parsing not choke and die. There's a bunch of missing information from IronPython's sys.version string, not much that can be done there. Should platform.py grow an 'implementation' option, so it can detect whether it's IronPython, CPython, Jython, or something else? Patch is against svn trunk. ---------------------------------------------------------------------- Comment By: Seo Sanghyeon (sanxiyn) Date: 2006-10-10 11:35 Message: Logged In: YES user_id=837148 The current patch doesn't parse sys.version from IronPython 1.0.1. IronPython 1.0 gives: IronPython 1.0.60816 on .NET 2.0.50727.42 IronPython 1.0.1 gives: IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-10-10 07:48 Message: Logged In: YES user_id=4771 Python2.5 has grown a sys.subversion attribute: ('CPython', 'trunk', '51999') The first field is intended to describe the exact implementation of Python. platform.py could return this if it is available. It should also probably try to use sys.version_info instead of, or in addition to, using a regexp on sys.version. One can hope that in the long term the version_info and the subversion attributes should eventually be supported by all Python implementation (PyPy...). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-25 19:30 Message: Logged In: YES user_id=38388 Thanks. I'll install IronPython and see what else needs to be done. I've already added a few fixes to make Jython play nice with platform.py that I'll check in as well. And yes: I'll add a python_implementation() function that returns 'CPython', 'Jython' and 'IronPython' as appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&group_id=5470 From noreply at sourceforge.net Tue Oct 10 06:45:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Oct 2006 21:45:53 -0700 Subject: [Patches] [ python-Patches-1574252 ] Add %var% support to ntpath.expandvars Message-ID: Patches item #1574252, was opened at 2006-10-09 21: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=1574252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Norkus (doubleyewdee) Assigned to: Nobody/Anonymous (nobody) Summary: Add %var% support to ntpath.expandvars Initial Comment: NT variables are passed around as %var% instead of $var or ${var}. Providing support for this gives a seamless user experience for NT users using Python. E.g. os.path.expandvars('%TEMP%') now does what is expected on NT. I updated the docstring, could not find any tests or documentation references in svn for this portion of code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 From noreply at sourceforge.net Tue Oct 10 16:00:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Oct 2006 07:00:51 -0700 Subject: [Patches] [ python-Patches-1574068 ] urllib2 - Fix line breaks in authorization headers Message-ID: Patches item #1574068, was opened at 2006-10-09 14:40 Message generated for change (Comment added) made by docwhat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Dial (geekmug) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 - Fix line breaks in authorization headers Initial Comment: urllib2 uses the wrong base64 encode function from the base64 library. This patch corrects that. Original bug report from "The Doctor What" I found a bug in urllib2's handling of basic HTTP authentication. urllib2 uses the base64.encodestring() method to encode the username:password. The problem is that base64.encodestring() adds newlines to wrap the encoded characters at the 76th column. This produces bogus request headers like this: ---------->8---------cut---------8<---------------- GET /some/url HTTP/1.1 Host: some.host Accept-Encoding: identity Authorization: Basic cmVhbGx5bG9uZ3VzZXJuYW1lOmFuZXZlbmxvbmdlcnBhc3N3b3JkdGhhdGdvZXNvbmFuZG9uYW5k b25hbmRvbmFuZG9u User-agent: some-agent ---------->8---------cut---------8<---------------- ---------------------------------------------------------------------- Comment By: Christian H?ltje (docwhat) Date: 2006-10-10 07:00 Message: Logged In: YES user_id=267 Cool! I'm glad my bug report helped. :-) ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-10-09 17:33 Message: Logged In: YES user_id=383208 Ah yes, you are correct that urllib has the same problem. I have attached a patch to correct all of those instances as well. It is note-worthy that the one usage of decodestring in urllib is correct (as it is decoding the body of the response and should reasonably expect to see newlines in that encoding). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-10-09 17:13 Message: Logged In: YES user_id=261020 urllib should also be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 From noreply at sourceforge.net Wed Oct 11 21:56:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Oct 2006 12:56:31 -0700 Subject: [Patches] [ python-Patches-1575506 ] Mailbox will lock properly after flush() Message-ID: Patches item #1575506, was opened at 2006-10-11 15:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Gauthier (deuxpi) Assigned to: Nobody/Anonymous (nobody) Summary: Mailbox will lock properly after flush() Initial Comment: The _singlefileMailbox class will try to lock the wrong file object after a flush(), resulting into an operation on a closed file object. The following code should illustrate the bug. See also the attached patch. >>> import mailbox >>> >>> box = mailbox.mbox('mbox') >>> msg = "Subject: sub\n\nbody\n" >>> box.add(msg) 0 >>> box.flush() >>> box.close() >>> >>> box = mailbox.mbox('mbox') >>> box.lock() >>> box.add(msg) 1 >>> box.flush() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/mailbox.py", line 581, in flush _lock_file(new_file, dotlock=False) File "/usr/lib/python2.5/mailbox.py", line 1847, in _lock_file fcntl.lockf(f, fcntl.LOCK_UN) ValueError: I/O operation on closed file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 From noreply at sourceforge.net Wed Oct 11 21:57:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Oct 2006 12:57:05 -0700 Subject: [Patches] [ python-Patches-1575506 ] Mailbox will not lock properly after flush() Message-ID: Patches item #1575506, was opened at 2006-10-11 15:56 Message generated for change (Settings changed) made by deuxpi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Gauthier (deuxpi) Assigned to: Nobody/Anonymous (nobody) >Summary: Mailbox will not lock properly after flush() Initial Comment: The _singlefileMailbox class will try to lock the wrong file object after a flush(), resulting into an operation on a closed file object. The following code should illustrate the bug. See also the attached patch. >>> import mailbox >>> >>> box = mailbox.mbox('mbox') >>> msg = "Subject: sub\n\nbody\n" >>> box.add(msg) 0 >>> box.flush() >>> box.close() >>> >>> box = mailbox.mbox('mbox') >>> box.lock() >>> box.add(msg) 1 >>> box.flush() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/mailbox.py", line 581, in flush _lock_file(new_file, dotlock=False) File "/usr/lib/python2.5/mailbox.py", line 1847, in _lock_file fcntl.lockf(f, fcntl.LOCK_UN) ValueError: I/O operation on closed file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 From noreply at sourceforge.net Thu Oct 12 15:02:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Oct 2006 06:02:57 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 16:39 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 2 Submitted By: Collin Winter (collinwinter) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 13:02 Message: Logged In: YES user_id=849994 Closing as well as bug #1517663. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-08-04 09:19 Message: Logged In: YES user_id=6656 I agree with arigo. Assigning to Neal so he can see this and get it off his "things to do for 2.5" list. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-25 18:08 Message: Logged In: YES user_id=4771 This patch is pointless. I recommend rejecting it. The crashers/gc_inspection.py was just one example among many of crashing Python with gc.get_referrers(). I don't see why we should care to fix just this specific way. What would be needed is a complete review, possibly with an API change to decouple object creation and GC registration, and appropriate documentation for extension module writers. I don't think it's likely to happen though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 06:28 Message: Logged In: YES user_id=33168 Note that the declaration of item needs to be moved to the top of the scope so it can compile with C89. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-05 22:31 Message: Logged In: YES user_id=80475 Crashers based on gc.get_referrers() should not be considered real bugs. It is certainly not worth complexifying the code or slowing it down just to preclude these little perverse safe-cracking exercises. Also, it is not worth the risk of introducing a real bug when the code was working fine. That being said, if the code is genuinely defective and has potential to cause real-world problems, then it should be fixed. I would think that if there were a long- standing problem with tuples, it would have manifested itself long ago. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-05 17:36 Message: Logged In: YES user_id=1344176 The improve_gc_inspection.patch file has been superseded by a patch attached to bug #1517663. The bug details another interpreter crash in the same vein as the one fix in tuple() by this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Thu Oct 12 20:57:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Oct 2006 11:57:09 -0700 Subject: [Patches] [ python-Patches-1576120 ] Support spawnvp[e] + use native execvp[e] on win32 Message-ID: Patches item #1576120, was opened at 2006-10-12 22: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=1576120&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: Support spawnvp[e] + use native execvp[e] on win32 Initial Comment: This patch adds support for os.spawnvp and os.spawnvpe by using implementation previously used on OS/2 only (not it is also used if HAVE_SPAWNVP is defined). Also it adds native os.execvp and os.execvpe (if HAVE_EXECVP is defined) and changes Lib/os.py so that it won't overwrite these functions if they exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576120&group_id=5470 From noreply at sourceforge.net Thu Oct 12 21:51:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Oct 2006 12:51:01 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 23:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Fri Oct 13 02:57:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Oct 2006 17:57:39 -0700 Subject: [Patches] [ python-Patches-1576313 ] os.execvp[e] on win32 fails for current directory Message-ID: Patches item #1576313, was opened at 2006-10-13 04: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=1576313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.execvp[e] on win32 fails for current directory Initial Comment: By convention when program is executed by searching path, the first directory to be searched should be the current directory. However on python this is not true: 1.c: int main() { return 1; } test.py: import os os.execvp('1', ('1',)) result: Traceback (most recent call last): File "C:\1\test.py", line 2, in os.execvp('1',('1',)) File "D:\Programs\ActiveState\Python25\lib\os.py", line 348, in execvp _execvpe(file, args) File "D:\Programs\ActiveState\Python25\lib\os.py", line 386, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory Attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 From noreply at sourceforge.net Fri Oct 13 10:17:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Oct 2006 01:17:43 -0700 Subject: [Patches] [ python-Patches-1569291 ] Speed-up in array_repeat() Message-ID: Patches item #1569291, was opened at 2006-10-02 13:30 Message generated for change (Comment added) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Lars Skovlund (lskovlund) Assigned to: Raymond Hettinger (rhettinger) Summary: Speed-up in array_repeat() Initial Comment: Use iterative doubling when extending the old array. This results in O(log n) calls to memcpy() instead of O(n). ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-13 08:17 Message: Logged In: YES user_id=364875 I'd assumed Python *didn't* double the size when resizing an array because of how much memory that wastes. May I suggest trying it with a multiplier of 1.5x, and comparing both CPU time and memory consumption? I find for these things that 1.5x is nearly as fast and wastes far less memory. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-08 00:59 Message: Logged In: YES user_id=80475 This patch is basically fine. Will neaten it up to match our source coding conventions and apply it when I get a chance. Py2.6 won't be out for a good while, so there is no hurry. ---------------------------------------------------------------------- Comment By: Lars Skovlund (lskovlund) Date: 2006-10-07 22:12 Message: Logged In: YES user_id=263372 I wrote this code for a university project I'm doing myself, which involves initializing a *very* large array (it's a remote memory system). It does help there, certainly; for medium-sized arrays, the improvement would be negligable, and for small ones it might even be worse. If you mean, have I benchmarked it with other people's code, no. I just thought I'd offer it to the community, since it has certainly helped me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 16:39 Message: Logged In: YES user_id=341410 Have you benchmarked this for repeats found "in the wild" to establish *observable* speedup for code that already exists? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 From qxudwb at cashiers.com Fri Oct 13 15:40:43 2006 From: qxudwb at cashiers.com (Jenny Moreno) Date: Fri, 13 Oct 2006 14:40:43 +0100 Subject: [Patches] indent unwound Message-ID: <452F975B.1030108@echoscreen.de> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061013/1a11c1d1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: educationally.gif Type: image/gif Size: 9019 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061013/1a11c1d1/attachment.gif From noreply at sourceforge.net Fri Oct 13 17:26:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Oct 2006 08:26:44 -0700 Subject: [Patches] [ python-Patches-1569291 ] Speed-up in array_repeat() Message-ID: Patches item #1569291, was opened at 2006-10-02 06:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Lars Skovlund (lskovlund) Assigned to: Raymond Hettinger (rhettinger) Summary: Speed-up in array_repeat() Initial Comment: Use iterative doubling when extending the old array. This results in O(log n) calls to memcpy() instead of O(n). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-13 08:26 Message: Logged In: YES user_id=341410 This patch has nothing to do with array resizing. It has to do with array initialization. ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-13 01:17 Message: Logged In: YES user_id=364875 I'd assumed Python *didn't* double the size when resizing an array because of how much memory that wastes. May I suggest trying it with a multiplier of 1.5x, and comparing both CPU time and memory consumption? I find for these things that 1.5x is nearly as fast and wastes far less memory. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-07 17:59 Message: Logged In: YES user_id=80475 This patch is basically fine. Will neaten it up to match our source coding conventions and apply it when I get a chance. Py2.6 won't be out for a good while, so there is no hurry. ---------------------------------------------------------------------- Comment By: Lars Skovlund (lskovlund) Date: 2006-10-07 15:12 Message: Logged In: YES user_id=263372 I wrote this code for a university project I'm doing myself, which involves initializing a *very* large array (it's a remote memory system). It does help there, certainly; for medium-sized arrays, the improvement would be negligable, and for small ones it might even be worse. If you mean, have I benchmarked it with other people's code, no. I just thought I'd offer it to the community, since it has certainly helped me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 09:39 Message: Logged In: YES user_id=341410 Have you benchmarked this for repeats found "in the wild" to establish *observable* speedup for code that already exists? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569291&group_id=5470 From noreply at sourceforge.net Sat Oct 14 02:09:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Oct 2006 17:09:04 -0700 Subject: [Patches] [ python-Patches-1576954 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1576954, was opened at 2006-10-14 00: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=1576954&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 From noreply at sourceforge.net Sat Oct 14 10:54:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 01:54:37 -0700 Subject: [Patches] [ python-Patches-1577078 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1577078, was opened at 2006-10-14 08: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=1577078&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 From noreply at sourceforge.net Sat Oct 14 10:56:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 01:56:25 -0700 Subject: [Patches] [ python-Patches-1577078 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1577078, was opened at 2006-10-14 08:54 Message generated for change (Comment added) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- >Comment By: Larry Hastings (lhastings) Date: 2006-10-14 08:56 Message: Logged In: YES user_id=364875 Sorry, I refreshed a page and it reposted the whole dang thing. If you see this patch, please remove it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 From noreply at sourceforge.net Sat Oct 14 10:56:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 01:56:54 -0700 Subject: [Patches] [ python-Patches-1577078 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1577078, was opened at 2006-10-14 08:54 Message generated for change (Settings changed) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-14 08:56 Message: Logged In: YES user_id=364875 Sorry, I refreshed a page and it reposted the whole dang thing. If you see this patch, please remove it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 From noreply at sourceforge.net Sat Oct 14 10:57:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 01:57:13 -0700 Subject: [Patches] [ python-Patches-1577078 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1577078, was opened at 2006-10-14 08:54 Message generated for change (Settings changed) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 >Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-14 08:56 Message: Logged In: YES user_id=364875 Sorry, I refreshed a page and it reposted the whole dang thing. If you see this patch, please remove it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577078&group_id=5470 From noreply at sourceforge.net Sat Oct 14 21:49:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 12:49:25 -0700 Subject: [Patches] [ python-Patches-1576954 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1576954, was opened at 2006-10-14 02:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:49 Message: Logged In: YES user_id=21627 The file is marked binary because it was that way in CVS; it was binary in CVS because not making it binary would cause a Unix checkout to use Unix EOL (i.e. LF only). That, in turn would cause VC to reject the files. Since the release tarball is made on Unix, it would have cause the released version not to build with VC. Patching over the entire file is fine in this case. Please indicate the base revision you had been using. For pythoncore.vcproj, svn should allow you to create a patch, though. Also, please do provide a backport for 2.5; I will then apply them all simultaneously (or shortly after another). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 From noreply at sourceforge.net Sat Oct 14 21:51:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 12:51:21 -0700 Subject: [Patches] [ python-Patches-1576313 ] os.execvp[e] on win32 fails for current directory Message-ID: Patches item #1576313, was opened at 2006-10-13 02:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.execvp[e] on win32 fails for current directory Initial Comment: By convention when program is executed by searching path, the first directory to be searched should be the current directory. However on python this is not true: 1.c: int main() { return 1; } test.py: import os os.execvp('1', ('1',)) result: Traceback (most recent call last): File "C:\1\test.py", line 2, in os.execvp('1',('1',)) File "D:\Programs\ActiveState\Python25\lib\os.py", line 348, in execvp _execvpe(file, args) File "D:\Programs\ActiveState\Python25\lib\os.py", line 386, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:51 Message: Logged In: YES user_id=21627 What convention are you referring to? By convention, you have to specify executables in the current directory with ./ if you don't have "." in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 From noreply at sourceforge.net Sat Oct 14 21:59:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 12:59:07 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 21:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:59 Message: Logged In: YES user_id=21627 The patch looks wrong. Opening a file with FILE_FLAG_BACKUP_SEMANTICS requires the SE_BACKUP_NAME. If the user does not have the privilege, opening will fail. This is wrong, because the user still might be able to change the time stamp of a regular file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Sat Oct 14 22:15:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 13:15:20 -0700 Subject: [Patches] [ python-Patches-1576313 ] os.execvp[e] on win32 fails for current directory Message-ID: Patches item #1576313, was opened at 2006-10-13 04:57 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.execvp[e] on win32 fails for current directory Initial Comment: By convention when program is executed by searching path, the first directory to be searched should be the current directory. However on python this is not true: 1.c: int main() { return 1; } test.py: import os os.execvp('1', ('1',)) result: Traceback (most recent call last): File "C:\1\test.py", line 2, in os.execvp('1',('1',)) File "D:\Programs\ActiveState\Python25\lib\os.py", line 348, in execvp _execvpe(file, args) File "D:\Programs\ActiveState\Python25\lib\os.py", line 386, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Snaury (snaury) Date: 2006-10-15 00:15 Message: Logged In: YES user_id=1197042 On win32 it is not so, execlp() in msvcrt, for example, will always looks in current directory before looking on PATH (and if I remember correctly OS/2 has the same rules, I don't remember PATH on OS/2 ever needing . in the PATH), so does CreateFile, so on win32 it's just what is expected. Sorry if I'm wrong though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 23:51 Message: Logged In: YES user_id=21627 What convention are you referring to? By convention, you have to specify executables in the current directory with ./ if you don't have "." in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 From noreply at sourceforge.net Sat Oct 14 22:31:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 13:31:18 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 23:51 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- >Comment By: Snaury (snaury) Date: 2006-10-15 00:31 Message: Logged In: YES user_id=1197042 You must be wrong. First Attempt: I'm enabling Guest account on my system (supposedly it has the least privileges), and try "file mtime" command on my Tcl build with identical fix applied: no error, file mtime was changed successfully. Second Attempt: While searching the net I found this post (http://www.cygwin.com/ml/cygwin/2006-03/msg00027.html) which leads me to the only conclusion that SE_BACKUP_NAME privilage is actually DISABLED by default, yet opening directories with FILE_FLAG_BACKUP_SEMANTICS always succeeds for me, which would not if it needed SE_BACKUP_NAME! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 23:59 Message: Logged In: YES user_id=21627 The patch looks wrong. Opening a file with FILE_FLAG_BACKUP_SEMANTICS requires the SE_BACKUP_NAME. If the user does not have the privilege, opening will fail. This is wrong, because the user still might be able to change the time stamp of a regular file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Sun Oct 15 01:06:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 16:06:03 -0700 Subject: [Patches] [ python-Patches-1576954 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1576954, was opened at 2006-10-14 00:09 Message generated for change (Comment added) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- >Comment By: Larry Hastings (lhastings) Date: 2006-10-14 23:06 Message: Logged In: YES user_id=364875 Okay, I've uploaded a patch for PCbuild/pythoncore.vcproj against the current 2.6 trunk, and a replacement PC/VC6/pythoncore.dsp for Python 2.5. You should still get the replacement PC/VC6/pythoncore.dsp for the 2.6 trunk from the first zip file I posted. One side note: when I build from scratch using VC7, and run "rt.bat", four tests fail because I don't have the libraries to build their modules: bz2, bsddb, tcl, and sqlite. When I build from scratch using VC6, those four tests fail, and two *more* fail: ctypes and xml_etree_c. This isn't all that surprising, as ElementTree and ctypes were new additions for 2.5. Since nobody was maintaining the VC6 build process, they didn't get new build processes made for them. I could take a stab at making ElementTree and ctypes build in VC6 for 2.5 and the (2.6) trunk if you like. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 19:49 Message: Logged In: YES user_id=21627 The file is marked binary because it was that way in CVS; it was binary in CVS because not making it binary would cause a Unix checkout to use Unix EOL (i.e. LF only). That, in turn would cause VC to reject the files. Since the release tarball is made on Unix, it would have cause the released version not to build with VC. Patching over the entire file is fine in this case. Please indicate the base revision you had been using. For pythoncore.vcproj, svn should allow you to create a patch, though. Also, please do provide a backport for 2.5; I will then apply them all simultaneously (or shortly after another). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 From noreply at sourceforge.net Sun Oct 15 01:08:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 16:08:49 -0700 Subject: [Patches] [ python-Patches-1576954 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1576954, was opened at 2006-10-14 00:09 Message generated for change (Comment added) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- >Comment By: Larry Hastings (lhastings) Date: 2006-10-14 23:08 Message: Logged In: YES user_id=364875 Oh, and, I thought I *had* been pretty good at indicating the base revision I was using. The first file I uploaded was called "lch.python.52326.win32.build.fixes.zip", and its description read "Two project files for pythoncore, based on trunk version 52326." I indicated the SVN revision number in both places. What more should I have done? ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-14 23:06 Message: Logged In: YES user_id=364875 Okay, I've uploaded a patch for PCbuild/pythoncore.vcproj against the current 2.6 trunk, and a replacement PC/VC6/pythoncore.dsp for Python 2.5. You should still get the replacement PC/VC6/pythoncore.dsp for the 2.6 trunk from the first zip file I posted. One side note: when I build from scratch using VC7, and run "rt.bat", four tests fail because I don't have the libraries to build their modules: bz2, bsddb, tcl, and sqlite. When I build from scratch using VC6, those four tests fail, and two *more* fail: ctypes and xml_etree_c. This isn't all that surprising, as ElementTree and ctypes were new additions for 2.5. Since nobody was maintaining the VC6 build process, they didn't get new build processes made for them. I could take a stab at making ElementTree and ctypes build in VC6 for 2.5 and the (2.6) trunk if you like. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 19:49 Message: Logged In: YES user_id=21627 The file is marked binary because it was that way in CVS; it was binary in CVS because not making it binary would cause a Unix checkout to use Unix EOL (i.e. LF only). That, in turn would cause VC to reject the files. Since the release tarball is made on Unix, it would have cause the released version not to build with VC. Patching over the entire file is fine in this case. Please indicate the base revision you had been using. For pythoncore.vcproj, svn should allow you to create a patch, though. Also, please do provide a backport for 2.5; I will then apply them all simultaneously (or shortly after another). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 From noreply at sourceforge.net Sun Oct 15 07:53:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Oct 2006 22:53:56 -0700 Subject: [Patches] [ python-Patches-1576954 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1576954, was opened at 2006-10-14 02:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 07:53 Message: Logged In: YES user_id=21627 The tests shouldn't be failing: the should be listed as (unexpected) skips. Whether or not you want to contribute project files for ET and ctypes is your choice: it will get fixed *only* if somebody contributes a fix, OTOH, it's not probably not important it gets fixed. As for the base revisions: you did it in a reasonable manner; I managed to ignore it regardless. I didn't think about the long file name (only recognized the first few letters, then shell completion took over), and I routinely ignore the file description, because people typically don't fill in something useful, anyway :-( ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-15 01:08 Message: Logged In: YES user_id=364875 Oh, and, I thought I *had* been pretty good at indicating the base revision I was using. The first file I uploaded was called "lch.python.52326.win32.build.fixes.zip", and its description read "Two project files for pythoncore, based on trunk version 52326." I indicated the SVN revision number in both places. What more should I have done? ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-15 01:06 Message: Logged In: YES user_id=364875 Okay, I've uploaded a patch for PCbuild/pythoncore.vcproj against the current 2.6 trunk, and a replacement PC/VC6/pythoncore.dsp for Python 2.5. You should still get the replacement PC/VC6/pythoncore.dsp for the 2.6 trunk from the first zip file I posted. One side note: when I build from scratch using VC7, and run "rt.bat", four tests fail because I don't have the libraries to build their modules: bz2, bsddb, tcl, and sqlite. When I build from scratch using VC6, those four tests fail, and two *more* fail: ctypes and xml_etree_c. This isn't all that surprising, as ElementTree and ctypes were new additions for 2.5. Since nobody was maintaining the VC6 build process, they didn't get new build processes made for them. I could take a stab at making ElementTree and ctypes build in VC6 for 2.5 and the (2.6) trunk if you like. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:49 Message: Logged In: YES user_id=21627 The file is marked binary because it was that way in CVS; it was binary in CVS because not making it binary would cause a Unix checkout to use Unix EOL (i.e. LF only). That, in turn would cause VC to reject the files. Since the release tarball is made on Unix, it would have cause the released version not to build with VC. Patching over the entire file is fine in this case. Please indicate the base revision you had been using. For pythoncore.vcproj, svn should allow you to create a patch, though. Also, please do provide a backport for 2.5; I will then apply them all simultaneously (or shortly after another). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 From noreply at sourceforge.net Sun Oct 15 09:57:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 00:57:00 -0700 Subject: [Patches] [ python-Patches-1576954 ] Fix VC6 build, remove redundant files for VC7 build Message-ID: Patches item #1576954, was opened at 2006-10-14 02:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Fix VC6 build, remove redundant files for VC7 build Initial Comment: The VC6 build for pythoncore (PC/VC6/pythoncore.dsp) was shipped broken in 2.5. This fixes it, as well as updating it for Python 2.6, and you can now once again produce python.exe (and python_d.exe) using VC6. (This fix could easily be backported to 2.5; I would be happy to submit that separately.) The VC7 build for pythoncore (PCBuild/pythoncore.vcproj) has two instances of "sha512module.c" and "signalmodule.c". While this is harmless, it is also totally unnecessary. The only change was to remove those two files. I built all four exes (python|python_d built with vc6|vc7) and ran the regression tests on them. They passed all expected tests except for the four modules I didn't build (tcl, sqlite, bz2, and bsddb). The patch is in the form of a zip file containing the build files themselves rather than a patch. This is because PC/VC6/pythoncore.dsp is marked as a binary file in svn, so "svn diff" declined to produce a good diff. I'm not sure *why* the file is marked this way; perhaps it's overly sensitive to EOL conventions? Anyway, I thought it best to honor this, and it was simpler to submit both as a single zip than as a zip and a patch, so here you are. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 09:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as 52333 and 52334. If you want to contribute further changes, please create a new issue. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 07:53 Message: Logged In: YES user_id=21627 The tests shouldn't be failing: the should be listed as (unexpected) skips. Whether or not you want to contribute project files for ET and ctypes is your choice: it will get fixed *only* if somebody contributes a fix, OTOH, it's not probably not important it gets fixed. As for the base revisions: you did it in a reasonable manner; I managed to ignore it regardless. I didn't think about the long file name (only recognized the first few letters, then shell completion took over), and I routinely ignore the file description, because people typically don't fill in something useful, anyway :-( ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-15 01:08 Message: Logged In: YES user_id=364875 Oh, and, I thought I *had* been pretty good at indicating the base revision I was using. The first file I uploaded was called "lch.python.52326.win32.build.fixes.zip", and its description read "Two project files for pythoncore, based on trunk version 52326." I indicated the SVN revision number in both places. What more should I have done? ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2006-10-15 01:06 Message: Logged In: YES user_id=364875 Okay, I've uploaded a patch for PCbuild/pythoncore.vcproj against the current 2.6 trunk, and a replacement PC/VC6/pythoncore.dsp for Python 2.5. You should still get the replacement PC/VC6/pythoncore.dsp for the 2.6 trunk from the first zip file I posted. One side note: when I build from scratch using VC7, and run "rt.bat", four tests fail because I don't have the libraries to build their modules: bz2, bsddb, tcl, and sqlite. When I build from scratch using VC6, those four tests fail, and two *more* fail: ctypes and xml_etree_c. This isn't all that surprising, as ElementTree and ctypes were new additions for 2.5. Since nobody was maintaining the VC6 build process, they didn't get new build processes made for them. I could take a stab at making ElementTree and ctypes build in VC6 for 2.5 and the (2.6) trunk if you like. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:49 Message: Logged In: YES user_id=21627 The file is marked binary because it was that way in CVS; it was binary in CVS because not making it binary would cause a Unix checkout to use Unix EOL (i.e. LF only). That, in turn would cause VC to reject the files. Since the release tarball is made on Unix, it would have cause the released version not to build with VC. Patching over the entire file is fine in this case. Please indicate the base revision you had been using. For pythoncore.vcproj, svn should allow you to create a patch, though. Also, please do provide a backport for 2.5; I will then apply them all simultaneously (or shortly after another). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 From noreply at sourceforge.net Sun Oct 15 10:26:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 01:26:19 -0700 Subject: [Patches] [ python-Patches-1577551 ] Add _ctypes, _ctypes_test, and _elementtree to VC6 build Message-ID: Patches item #1577551, was opened at 2006-10-15 08:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Add _ctypes, _ctypes_test, and _elementtree to VC6 build Initial Comment: Following patch #1576954: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 I've created VC6 .dsp files for _ctypes, _ctypes_test, and _elementtree. VC6 builds now have all the same modules, and pass all the same tests, that the VC7 build does. (Hooray?) The zip file has three new files: _ctypes.dsp _ctypes_test.dsp _elementtree.dsp And a replacement for one file: pcbuild.dsw Since these all need to be checked in as binary, I've sent you the whole file(s) instead of diffs. Note: the attached build files work for both 2.5 *and* 2.6. I hope you check 'em in in both places. Enjoy! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577551&group_id=5470 From noreply at sourceforge.net Sun Oct 15 10:45:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 01:45:19 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 21:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Snaury (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 10:45 Message: Logged In: YES user_id=21627 It seems you are right. Thanks for the patch; committed as r52335. Can you please state your real name? ---------------------------------------------------------------------- Comment By: Snaury (snaury) Date: 2006-10-14 22:31 Message: Logged In: YES user_id=1197042 You must be wrong. First Attempt: I'm enabling Guest account on my system (supposedly it has the least privileges), and try "file mtime" command on my Tcl build with identical fix applied: no error, file mtime was changed successfully. Second Attempt: While searching the net I found this post (http://www.cygwin.com/ml/cygwin/2006-03/msg00027.html) which leads me to the only conclusion that SE_BACKUP_NAME privilage is actually DISABLED by default, yet opening directories with FILE_FLAG_BACKUP_SEMANTICS always succeeds for me, which would not if it needed SE_BACKUP_NAME! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:59 Message: Logged In: YES user_id=21627 The patch looks wrong. Opening a file with FILE_FLAG_BACKUP_SEMANTICS requires the SE_BACKUP_NAME. If the user does not have the privilege, opening will fail. This is wrong, because the user still might be able to change the time stamp of a regular file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Sun Oct 15 10:53:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 01:53:19 -0700 Subject: [Patches] [ python-Patches-1577551 ] Add _ctypes, _ctypes_test, and _elementtree to VC6 build Message-ID: Patches item #1577551, was opened at 2006-10-15 10:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Add _ctypes, _ctypes_test, and _elementtree to VC6 build Initial Comment: Following patch #1576954: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 I've created VC6 .dsp files for _ctypes, _ctypes_test, and _elementtree. VC6 builds now have all the same modules, and pass all the same tests, that the VC7 build does. (Hooray?) The zip file has three new files: _ctypes.dsp _ctypes_test.dsp _elementtree.dsp And a replacement for one file: pcbuild.dsw Since these all need to be checked in as binary, I've sent you the whole file(s) instead of diffs. Note: the attached build files work for both 2.5 *and* 2.6. I hope you check 'em in in both places. Enjoy! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 10:53 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52336 and r52337. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577551&group_id=5470 From noreply at sourceforge.net Sun Oct 15 11:47:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 02:47:11 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 23:51 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- >Comment By: Alexey Borzenkov (snaury) Date: 2006-10-15 13:47 Message: Logged In: YES user_id=1197042 It should now be displayed as public name on SourceForge. :) Btw, would this patch go into 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 12:45 Message: Logged In: YES user_id=21627 It seems you are right. Thanks for the patch; committed as r52335. Can you please state your real name? ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-15 00:31 Message: Logged In: YES user_id=1197042 You must be wrong. First Attempt: I'm enabling Guest account on my system (supposedly it has the least privileges), and try "file mtime" command on my Tcl build with identical fix applied: no error, file mtime was changed successfully. Second Attempt: While searching the net I found this post (http://www.cygwin.com/ml/cygwin/2006-03/msg00027.html) which leads me to the only conclusion that SE_BACKUP_NAME privilage is actually DISABLED by default, yet opening directories with FILE_FLAG_BACKUP_SEMANTICS always succeeds for me, which would not if it needed SE_BACKUP_NAME! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 23:59 Message: Logged In: YES user_id=21627 The patch looks wrong. Opening a file with FILE_FLAG_BACKUP_SEMANTICS requires the SE_BACKUP_NAME. If the user does not have the privilege, opening will fail. This is wrong, because the user still might be able to change the time stamp of a regular file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Sun Oct 15 13:44:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 04:44:46 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 21:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 13:44 Message: Logged In: YES user_id=21627 I committed it to the trunk only at the moment. Whether it can go into 2.5 still needs to be discussed (again, it's a new feature: something that you couldn't do before now becomes possible). ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-15 11:47 Message: Logged In: YES user_id=1197042 It should now be displayed as public name on SourceForge. :) Btw, would this patch go into 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 10:45 Message: Logged In: YES user_id=21627 It seems you are right. Thanks for the patch; committed as r52335. Can you please state your real name? ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-14 22:31 Message: Logged In: YES user_id=1197042 You must be wrong. First Attempt: I'm enabling Guest account on my system (supposedly it has the least privileges), and try "file mtime" command on my Tcl build with identical fix applied: no error, file mtime was changed successfully. Second Attempt: While searching the net I found this post (http://www.cygwin.com/ml/cygwin/2006-03/msg00027.html) which leads me to the only conclusion that SE_BACKUP_NAME privilage is actually DISABLED by default, yet opening directories with FILE_FLAG_BACKUP_SEMANTICS always succeeds for me, which would not if it needed SE_BACKUP_NAME! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:59 Message: Logged In: YES user_id=21627 The patch looks wrong. Opening a file with FILE_FLAG_BACKUP_SEMANTICS requires the SE_BACKUP_NAME. If the user does not have the privilege, opening will fail. This is wrong, because the user still might be able to change the time stamp of a regular file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Sun Oct 15 13:53:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 04:53:54 -0700 Subject: [Patches] [ python-Patches-1577551 ] Add _ctypes, _ctypes_test, and _elementtree to VC6 build Message-ID: Patches item #1577551, was opened at 2006-10-15 10:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577551&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: Add _ctypes, _ctypes_test, and _elementtree to VC6 build Initial Comment: Following patch #1576954: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576954&group_id=5470 I've created VC6 .dsp files for _ctypes, _ctypes_test, and _elementtree. VC6 builds now have all the same modules, and pass all the same tests, that the VC7 build does. (Hooray?) The zip file has three new files: _ctypes.dsp _ctypes_test.dsp _elementtree.dsp And a replacement for one file: pcbuild.dsw Since these all need to be checked in as binary, I've sent you the whole file(s) instead of diffs. Note: the attached build files work for both 2.5 *and* 2.6. I hope you check 'em in in both places. Enjoy! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 13:53 Message: Logged In: YES user_id=21627 As Hirokazu Yamamoto points out, this still doesn't make the VC6 build create all the modules that PCbuild creates, e.g. sqlite3 is still missing. See also python.org/sf/1457736. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 10:53 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52336 and r52337. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577551&group_id=5470 From noreply at sourceforge.net Sun Oct 15 13:56:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 04:56:30 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 23:27 Message generated for change (Comment added) made by alexanderweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Simon Law (sfllaw) Assigned to: Neal Norwitz (nnorwitz) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- Comment By: Alexander Schremmer (alexanderweb) Date: 2006-10-15 13:56 Message: Logged In: YES user_id=254738 The related security advisory is http://www.python.org/news/ security/PSF-2006-001/ ---------------------------------------------------------------------- Comment By: Alexander Schremmer (alexanderweb) Date: 2006-10-08 00:43 Message: Logged In: YES user_id=254738 The CVE issue for this bug is CVE-2006-4980, which currently still under review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-07 19:00 Message: Logged In: YES user_id=849994 Attaching a code file containing a Python version of the Unicode string escape routine for UCS-4 builds. (it only replaces repr() if called from python, so not everything is fixed, esp. "%r") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 10:26 Message: Logged In: YES user_id=849994 Applied to 2.4 in revision 51466. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 00:22 Message: Logged In: YES user_id=33168 Committed revision 51448. (2.6) Committed revision 51450. (2.5) Someone should backport to 2.4, leaving open until then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Sun Oct 15 14:06:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 05:06:46 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 14:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 14:06 Message: Logged In: YES user_id=21627 Many of these issues have been fixed. Can you please update the patch again to fix the remaining ones? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 15:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 06:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 07:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 07:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-06 20:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-26 19:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Sun Oct 15 16:24:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 07:24:13 -0700 Subject: [Patches] [ python-Patches-1576166 ] os.utime acess denied with directories on win32 Message-ID: Patches item #1576166, was opened at 2006-10-12 21:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.6 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime acess denied with directories on win32 Initial Comment: Try the following code: >>> import os >>> os.mkdir('8') >>> os.utime('8',None) Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] Access is denied: '8' >>> This fix passes correct flags to CreateFile to successfully open directories (when built with wide filenames support, in other case native utime is used and msvcrt has the very same bug). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 16:24 Message: Logged In: YES user_id=21627 The release manager has decided that this feature shouldn't be backported (as it is a new feature, and a marginal one). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 13:44 Message: Logged In: YES user_id=21627 I committed it to the trunk only at the moment. Whether it can go into 2.5 still needs to be discussed (again, it's a new feature: something that you couldn't do before now becomes possible). ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-15 11:47 Message: Logged In: YES user_id=1197042 It should now be displayed as public name on SourceForge. :) Btw, would this patch go into 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 10:45 Message: Logged In: YES user_id=21627 It seems you are right. Thanks for the patch; committed as r52335. Can you please state your real name? ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-14 22:31 Message: Logged In: YES user_id=1197042 You must be wrong. First Attempt: I'm enabling Guest account on my system (supposedly it has the least privileges), and try "file mtime" command on my Tcl build with identical fix applied: no error, file mtime was changed successfully. Second Attempt: While searching the net I found this post (http://www.cygwin.com/ml/cygwin/2006-03/msg00027.html) which leads me to the only conclusion that SE_BACKUP_NAME privilage is actually DISABLED by default, yet opening directories with FILE_FLAG_BACKUP_SEMANTICS always succeeds for me, which would not if it needed SE_BACKUP_NAME! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 21:59 Message: Logged In: YES user_id=21627 The patch looks wrong. Opening a file with FILE_FLAG_BACKUP_SEMANTICS requires the SE_BACKUP_NAME. If the user does not have the privilege, opening will fail. This is wrong, because the user still might be able to change the time stamp of a regular file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576166&group_id=5470 From noreply at sourceforge.net Sun Oct 15 16:32:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 07:32:08 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 22:40 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-15 23:32 Message: Logged In: YES user_id=1200846 I've done rough merge. But I don't understand every difference between base and working copy, I'll check detail tomorrow. (Some differences comes from the fact I copied compiler options from other dsp files. But I don't know this differences cause something) This is current summary... * zlib.dsp: no longer needed so removed. * _sqlite3.dsp: added. * _ssl.mak: /DWIN32 and user32.lib advapi32.lib are needed. * _bsddb.dsp and others: use newer version of external files like PCBuild. * bz2.dsp: avoid "Special Build Tool". I experienced error when built this module from VisualC++6 IDE. Need to build bzip2-1.0.3 separately. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 21:06 Message: Logged In: YES user_id=21627 Many of these issues have been fixed. Can you please update the patch again to fix the remaining ones? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 22:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-07 03:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 02:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Sun Oct 15 21:33:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 12:33:35 -0700 Subject: [Patches] [ python-Patches-1577756 ] newline in -DSVNVERSION=\"`LANG=C svnversion .`\" Message-ID: Patches item #1577756, was opened at 2006-10-15 21:33 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=1577756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Str?nger (schmaller) Assigned to: Nobody/Anonymous (nobody) Summary: newline in -DSVNVERSION=\"`LANG=C svnversion .`\" Initial Comment: gcc (version 3.4.4) fails to compile Modules/getbuildinfo.c, since it works as documented and cuts the definition of SVNVERSION at the first newline and so there is an unbalanced double quote. citation of the gcc manpage: -D name=definition Predefine name as a macro, with definition definition. The contents of definition are tokenized and processed as if they appeared during translation phase three in a #define directive. In particular, the definition will be truncated by embedded newline characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 From noreply at sourceforge.net Sun Oct 15 23:12:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Oct 2006 14:12:44 -0700 Subject: [Patches] [ python-Patches-1577756 ] newline in -DSVNVERSION=\"`LANG=C svnversion .`\" Message-ID: Patches item #1577756, was opened at 2006-10-15 21:33 Message generated for change (Comment added) made by schmaller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Deleted >Resolution: Wont Fix Priority: 5 Submitted By: Daniel Str?nger (schmaller) Assigned to: Nobody/Anonymous (nobody) Summary: newline in -DSVNVERSION=\"`LANG=C svnversion .`\" Initial Comment: gcc (version 3.4.4) fails to compile Modules/getbuildinfo.c, since it works as documented and cuts the definition of SVNVERSION at the first newline and so there is an unbalanced double quote. citation of the gcc manpage: -D name=definition Predefine name as a macro, with definition definition. The contents of definition are tokenized and processed as if they appeared during translation phase three in a #define directive. In particular, the definition will be truncated by embedded newline characters. ---------------------------------------------------------------------- >Comment By: Daniel Str?nger (schmaller) Date: 2006-10-15 23:12 Message: Logged In: YES user_id=922469 The patch don't fix it and i think it's not a problem of Python. I apologize for spamming the patch system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 From noreply at sourceforge.net Mon Oct 16 13:44:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Oct 2006 04:44:38 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 22:40 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-16 20:44 Message: Logged In: YES user_id=1200846 I updated patch. Addition to previous my comment.... * I believe no need to add header files into dsp files because VC6 detects header modification and compiles corresponding cpp files correctly. * Still I don't know well, changed some compiler/linker options to follow pythoncore.dsp way. (/o "NUL", /MTd=>/MDd /ZI=>/Zi, SUBTRACT LINK32 /pdb:none, ported /base value from PCBuild) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-15 23:32 Message: Logged In: YES user_id=1200846 I've done rough merge. But I don't understand every difference between base and working copy, I'll check detail tomorrow. (Some differences comes from the fact I copied compiler options from other dsp files. But I don't know this differences cause something) This is current summary... * zlib.dsp: no longer needed so removed. * _sqlite3.dsp: added. * _ssl.mak: /DWIN32 and user32.lib advapi32.lib are needed. * _bsddb.dsp and others: use newer version of external files like PCBuild. * bz2.dsp: avoid "Special Build Tool". I experienced error when built this module from VisualC++6 IDE. Need to build bzip2-1.0.3 separately. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 21:06 Message: Logged In: YES user_id=21627 Many of these issues have been fixed. Can you please update the patch again to fix the remaining ones? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 22:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-07 03:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 02:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Tue Oct 17 00:47:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Oct 2006 15:47:23 -0700 Subject: [Patches] [ python-Patches-1574252 ] Add %var% support to ntpath.expandvars Message-ID: Patches item #1574252, was opened at 2006-10-09 21:45 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Norkus (doubleyewdee) Assigned to: Nobody/Anonymous (nobody) Summary: Add %var% support to ntpath.expandvars Initial Comment: NT variables are passed around as %var% instead of $var or ${var}. Providing support for this gives a seamless user experience for NT users using Python. E.g. os.path.expandvars('%TEMP%') now does what is expected on NT. I updated the docstring, could not find any tests or documentation references in svn for this portion of code. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-16 15:47 Message: Logged In: YES user_id=341410 See also: http://python.org/sf/796219 and http://python.org/sf/957650 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 From noreply at sourceforge.net Tue Oct 17 06:04:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Oct 2006 21:04:01 -0700 Subject: [Patches] [ python-Patches-1578643 ] various datetime methods fail in restricted mode Message-ID: Patches item #1578643, was opened at 2006-10-17 14: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=1578643&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: various datetime methods fail in restricted mode Initial Comment: The following methods fail in restricted execution mode, because they try to import the time module: datetime.datetime.strftime datetime.datetime.strptime datetime.datetime.timetuple datetime.datetime.utctimetuple datetime.time.time datetime.date.timetuple Example of the problem: >>> import datetime >>> script = 'print dt; print dt.strftime("x")' >>> exec script in {'dt':datetime.datetime(2006,1,1)} 2006-01-01 00:00:00 x >>> exec script in {'dt':datetime.datetime(2006,1,1),'__builtins__':{}} 2006-01-01 00:00:00 Traceback (most recent call last): File "", line 1, in ? File "", line 1, in ? KeyError: '__import__' The attached adjusts the datetime module so that the time module is imported in the initialisation of the datetime module. This allows these methods to be used in restricted execution mode. If the time module is not available, then the datetime module will not be importable either after this patch. Previously the datetime module would be importable but the methods listed above would raise exceptions. If this situation is worth considering then I can adjust the patch accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578643&group_id=5470 From noreply at sourceforge.net Tue Oct 17 16:27:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 07:27:19 -0700 Subject: [Patches] [ python-Patches-1578999 ] PyErr_Format corrections Message-ID: Patches item #1578999, was opened at 2006-10-17 16:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578999&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Jack Jansen (jackjansen) Summary: PyErr_Format corrections Initial Comment: The attached patch corrects a number of errors in the usage of PyErr_Format, for the Mac specific modules. It should be reviewed for technical correctness wrt. the Apple API, and also wrt. whether the patch changes generated files. In particular, the error corrections are: - OSErr is a 16-bit value, can't parse with 'i' - MusicMIDIPacket::data is UINT8[249], parsing it with s# won't work, as s# outputs a char*. I *assume* QtMusicMIDIPacket_Convert wants to get the string into the data buffer - In Qt_TuneSetHeader, an int* is passed to an 's' argument. Not sure whether this is correct: shouldn't there be a requirement that the string is a multiple of sizeof(int) in length? - SndCmd_Convert parses a char* into a long. This is correct in terms of size for both 32-bit and 64-bit systems. Is it also correct logically? (i.e. is param2 really a pointer?) - TXNScrollBarState is a single-byte type - ScrapFlavorFlags is an unsigned type - Boolean is a single-byte type - CFStringEncoding is now parsed through a long temporary variable, as it's not clear what format code would be correct ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578999&group_id=5470 From noreply at sourceforge.net Tue Oct 17 16:27:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 07:27:40 -0700 Subject: [Patches] [ python-Patches-1578999 ] PyArg_ParseTuple corrections Message-ID: Patches item #1578999, was opened at 2006-10-17 16:27 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578999&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Jack Jansen (jackjansen) >Summary: PyArg_ParseTuple corrections Initial Comment: The attached patch corrects a number of errors in the usage of PyErr_Format, for the Mac specific modules. It should be reviewed for technical correctness wrt. the Apple API, and also wrt. whether the patch changes generated files. In particular, the error corrections are: - OSErr is a 16-bit value, can't parse with 'i' - MusicMIDIPacket::data is UINT8[249], parsing it with s# won't work, as s# outputs a char*. I *assume* QtMusicMIDIPacket_Convert wants to get the string into the data buffer - In Qt_TuneSetHeader, an int* is passed to an 's' argument. Not sure whether this is correct: shouldn't there be a requirement that the string is a multiple of sizeof(int) in length? - SndCmd_Convert parses a char* into a long. This is correct in terms of size for both 32-bit and 64-bit systems. Is it also correct logically? (i.e. is param2 really a pointer?) - TXNScrollBarState is a single-byte type - ScrapFlavorFlags is an unsigned type - Boolean is a single-byte type - CFStringEncoding is now parsed through a long temporary variable, as it's not clear what format code would be correct ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578999&group_id=5470 From noreply at sourceforge.net Tue Oct 17 16:28:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 07:28:13 -0700 Subject: [Patches] [ python-Patches-1578999 ] PyArg_ParseTuple corrections Message-ID: Patches item #1578999, was opened at 2006-10-17 16:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578999&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Jack Jansen (jackjansen) Summary: PyArg_ParseTuple corrections Initial Comment: The attached patch corrects a number of errors in the usage of PyErr_Format, for the Mac specific modules. It should be reviewed for technical correctness wrt. the Apple API, and also wrt. whether the patch changes generated files. In particular, the error corrections are: - OSErr is a 16-bit value, can't parse with 'i' - MusicMIDIPacket::data is UINT8[249], parsing it with s# won't work, as s# outputs a char*. I *assume* QtMusicMIDIPacket_Convert wants to get the string into the data buffer - In Qt_TuneSetHeader, an int* is passed to an 's' argument. Not sure whether this is correct: shouldn't there be a requirement that the string is a multiple of sizeof(int) in length? - SndCmd_Convert parses a char* into a long. This is correct in terms of size for both 32-bit and 64-bit systems. Is it also correct logically? (i.e. is param2 really a pointer?) - TXNScrollBarState is a single-byte type - ScrapFlavorFlags is an unsigned type - Boolean is a single-byte type - CFStringEncoding is now parsed through a long temporary variable, as it's not clear what format code would be correct ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 16:28 Message: Logged In: YES user_id=21627 PyArg_ParseTuple, I mean, not PyErr_Format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578999&group_id=5470 From noreply at sourceforge.net Tue Oct 17 17:24:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 08:24:04 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 14:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:24 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52356 and r52357. If you have further modifications to make, please submit them as a new patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-16 13:44 Message: Logged In: YES user_id=1200846 I updated patch. Addition to previous my comment.... * I believe no need to add header files into dsp files because VC6 detects header modification and compiles corresponding cpp files correctly. * Still I don't know well, changed some compiler/linker options to follow pythoncore.dsp way. (/o "NUL", /MTd=>/MDd /ZI=>/Zi, SUBTRACT LINK32 /pdb:none, ported /base value from PCBuild) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-15 16:32 Message: Logged In: YES user_id=1200846 I've done rough merge. But I don't understand every difference between base and working copy, I'll check detail tomorrow. (Some differences comes from the fact I copied compiler options from other dsp files. But I don't know this differences cause something) This is current summary... * zlib.dsp: no longer needed so removed. * _sqlite3.dsp: added. * _ssl.mak: /DWIN32 and user32.lib advapi32.lib are needed. * _bsddb.dsp and others: use newer version of external files like PCBuild. * bz2.dsp: avoid "Special Build Tool". I experienced error when built this module from VisualC++6 IDE. Need to build bzip2-1.0.3 separately. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 14:06 Message: Logged In: YES user_id=21627 Many of these issues have been fixed. Can you please update the patch again to fix the remaining ones? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 15:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 06:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 07:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 07:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-06 20:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-26 19:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Tue Oct 17 20:00:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 11:00:16 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 22:40 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-18 03:00 Message: Logged In: YES user_id=1200846 Thank you for commit. But, well, zlib.dsp still exists. (empty file) Could you remove it from repositry? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-18 00:24 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52356 and r52357. If you have further modifications to make, please submit them as a new patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-16 20:44 Message: Logged In: YES user_id=1200846 I updated patch. Addition to previous my comment.... * I believe no need to add header files into dsp files because VC6 detects header modification and compiles corresponding cpp files correctly. * Still I don't know well, changed some compiler/linker options to follow pythoncore.dsp way. (/o "NUL", /MTd=>/MDd /ZI=>/Zi, SUBTRACT LINK32 /pdb:none, ported /base value from PCBuild) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-15 23:32 Message: Logged In: YES user_id=1200846 I've done rough merge. But I don't understand every difference between base and working copy, I'll check detail tomorrow. (Some differences comes from the fact I copied compiler options from other dsp files. But I don't know this differences cause something) This is current summary... * zlib.dsp: no longer needed so removed. * _sqlite3.dsp: added. * _ssl.mak: /DWIN32 and user32.lib advapi32.lib are needed. * _bsddb.dsp and others: use newer version of external files like PCBuild. * bz2.dsp: avoid "Special Build Tool". I experienced error when built this module from VisualC++6 IDE. Need to build bzip2-1.0.3 separately. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 21:06 Message: Logged In: YES user_id=21627 Many of these issues have been fixed. Can you please update the patch again to fix the remaining ones? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 22:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-07 03:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 02:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Tue Oct 17 20:10:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 11:10:52 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 14:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 20:10 Message: Logged In: YES user_id=21627 Thanks for pointing it out; done. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-17 20:00 Message: Logged In: YES user_id=1200846 Thank you for commit. But, well, zlib.dsp still exists. (empty file) Could you remove it from repositry? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:24 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52356 and r52357. If you have further modifications to make, please submit them as a new patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-16 13:44 Message: Logged In: YES user_id=1200846 I updated patch. Addition to previous my comment.... * I believe no need to add header files into dsp files because VC6 detects header modification and compiles corresponding cpp files correctly. * Still I don't know well, changed some compiler/linker options to follow pythoncore.dsp way. (/o "NUL", /MTd=>/MDd /ZI=>/Zi, SUBTRACT LINK32 /pdb:none, ported /base value from PCBuild) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-10-15 16:32 Message: Logged In: YES user_id=1200846 I've done rough merge. But I don't understand every difference between base and working copy, I'll check detail tomorrow. (Some differences comes from the fact I copied compiler options from other dsp files. But I don't know this differences cause something) This is current summary... * zlib.dsp: no longer needed so removed. * _sqlite3.dsp: added. * _ssl.mak: /DWIN32 and user32.lib advapi32.lib are needed. * _bsddb.dsp and others: use newer version of external files like PCBuild. * bz2.dsp: avoid "Special Build Tool". I experienced error when built this module from VisualC++6 IDE. Need to build bzip2-1.0.3 separately. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-15 14:06 Message: Logged In: YES user_id=21627 Many of these issues have been fixed. Can you please update the patch again to fix the remaining ones? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 15:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 06:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 07:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 07:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-06 20:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-26 19:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Tue Oct 17 21:56:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Oct 2006 12:56:30 -0700 Subject: [Patches] [ python-Patches-1353872 ] a faster Modulefinder Message-ID: Patches item #1353872, was opened at 2005-11-11 12:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1353872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: a faster Modulefinder Initial Comment: py2exe uses Python's modulefinder to find the modules and packages that belong to one or more scripts. For not too small projects, the runtime of modulefinder is quite long. On my system, the time to find all 533 modules my project needs is around 48 seconds. So, I profiled the Python 2.4 modulefinder, and patched it for a speedup of a factor of ~2.5 - the time required to find the modules drops to around 19 seconds. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-10-17 21:56 Message: Logged In: YES user_id=11105 This patch is out of date. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-11-11 13:02 Message: Logged In: YES user_id=11105 Here is a description of the changes in the patch: Modulefinder's scan_code method did call ord() on each character of the co.co_code string, that took the most time, and it built the argument (again with ord() calls) of each bytecode that had one, even if it was never used. The patch changes the code to - work on the characters of the co.co_code string, avoiding the calls to ord() altogether - create the bytecodes argument only when needed, - create the bytecode with struct.pack which is faster. I did not stop there, so other changes were that the objects that scan_code needs most are passed as default arguments to the functions instead of looking them up in the global namespace. This patch will probably be in the next py2exe release, so it will undergo some testing. I would appreciate comments on the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1353872&group_id=5470 From noreply at sourceforge.net Wed Oct 18 18:36:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Oct 2006 09:36:33 -0700 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 16:20 Message generated for change (Comment added) made by dfaure_kde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. 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: David Faure (dfaure_kde) Date: 2006-10-18 18:36 Message: Logged In: YES user_id=591851 This API is seriously broken. datetime.h says static PyDateTime_CAPI *PyDateTimeAPI; which means that including this file from two C (or C++) files leads to two independent PyDateTimeAPI symbols - calling PyDateTime_IMPORT in one file still leaves PyDateTimeAPI being 0 in the other! I double checked, and this happens with both C and C++. This needs to be revised so that there is indeed only one PyDateTimeAPI symbol, no matter how many files include that file. s/static/extern/ and defining "PyDateTime_CAPI *PyDateTimeAPI;" in one of the c files in python. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-07-06 16: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 20: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 19: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-21 00: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 17: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 15: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-06 01: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-06 01: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 19: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 19: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-06-01 05: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 21: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 21: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 21:25 Message: Logged In: YES user_id=38388 Tim, please review. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-05-26 21: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 18: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 10: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 19: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 19: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 18: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 17: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 16: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 18: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 17: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-06 00: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 19: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 19: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 18: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 16: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 16: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-26 00:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 12: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 22: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 21: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 19: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-26 04: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 Thu Oct 19 19:12:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 10:12:02 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19: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=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Fri Oct 20 00:13:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Oct 2006 15:13:07 -0700 Subject: [Patches] [ python-Patches-1580872 ] Duplicated declaration of PyCallable_Check Message-ID: Patches item #1580872, was opened at 2006-10-20 00:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Duplicated declaration of PyCallable_Check Initial Comment: [forwarded from http://bugs.debian.org/388713] "the other declaration is found in object.h. The problem is a bit annoying for us, as we use Python in an environment where we wish to consider warnings as errors to be fixed." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580872&group_id=5470 From noreply at sourceforge.net Fri Oct 20 09:19:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 00:19:14 -0700 Subject: [Patches] [ python-Patches-1581073 ] Allow textwrap to preserve leading and trailing whitespace Message-ID: Patches item #1581073, was opened at 2006-10-20 09:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1581073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dwayne Bailey (dwaynebailey) Assigned to: Nobody/Anonymous (nobody) Summary: Allow textwrap to preserve leading and trailing whitespace Initial Comment: The attached file add the ability to preserve whitespace in textwrap. Usefull where you are using textwrap in instances where whitespace is significant (I'm using it to reflow Gettext PO file text). By default the current behaviour is preserver so the added option is called drop_whitespace and by default it is set to True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1581073&group_id=5470 From noreply at sourceforge.net Fri Oct 20 09:22:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 00:22:11 -0700 Subject: [Patches] [ python-Patches-1581073 ] Allow textwrap to preserve leading and trailing whitespace Message-ID: Patches item #1581073, was opened at 2006-10-20 09:19 Message generated for change (Comment added) made by dwaynebailey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1581073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dwayne Bailey (dwaynebailey) >Assigned to: Greg Ward (gward) Summary: Allow textwrap to preserve leading and trailing whitespace Initial Comment: The attached file add the ability to preserve whitespace in textwrap. Usefull where you are using textwrap in instances where whitespace is significant (I'm using it to reflow Gettext PO file text). By default the current behaviour is preserver so the added option is called drop_whitespace and by default it is set to True. ---------------------------------------------------------------------- >Comment By: Dwayne Bailey (dwaynebailey) Date: 2006-10-20 09:22 Message: Logged In: YES user_id=937299 Hi Greg, I'm assigning this to you as you seem to be the original author and suggested that was the best step in this email: http://mail.python.org/pipermail/python-dev/2005-February/051769.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1581073&group_id=5470 From noreply at sourceforge.net Fri Oct 20 09:56:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 00:56:48 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Fri Oct 20 10:50:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 01:50:04 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 10:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Fri Oct 20 19:48:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Oct 2006 10:48:14 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 19:48 Message: Logged In: YES user_id=21627 This should be discussed on python-dev. I don't think the change in return type should be backported - it has a real chance of breaking applications (which suddenly start seeing Unicode strings where none were before). Always using the file system encoding (instead of the default encoding) but leaving the return type might be considered a bug fix. It also might be considered a new feature: you can now do things you couldn't before. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 10:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Sun Oct 22 11:29:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 02:29:33 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 11:29 Message: Logged In: YES user_id=580910 readlink2.patch cleans up the unicode check and adds a documentation update. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 19:48 Message: Logged In: YES user_id=21627 This should be discussed on python-dev. I don't think the change in return type should be backported - it has a real chance of breaking applications (which suddenly start seeing Unicode strings where none were before). Always using the file system encoding (instead of the default encoding) but leaving the return type might be considered a bug fix. It also might be considered a new feature: you can now do things you couldn't before. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 10:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Sun Oct 22 12:37:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 03:37:31 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 12:37 Message: Logged In: YES user_id=21627 The patch is fine, please apply. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 11:29 Message: Logged In: YES user_id=580910 readlink2.patch cleans up the unicode check and adds a documentation update. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 19:48 Message: Logged In: YES user_id=21627 This should be discussed on python-dev. I don't think the change in return type should be backported - it has a real chance of breaking applications (which suddenly start seeing Unicode strings where none were before). Always using the file system encoding (instead of the default encoding) but leaving the return type might be considered a bug fix. It also might be considered a new feature: you can now do things you couldn't before. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 10:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Sun Oct 22 12:38:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 03:38:01 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 12:37 Message: Logged In: YES user_id=21627 The patch is fine, please apply. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 11:29 Message: Logged In: YES user_id=580910 readlink2.patch cleans up the unicode check and adds a documentation update. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 19:48 Message: Logged In: YES user_id=21627 This should be discussed on python-dev. I don't think the change in return type should be backported - it has a real chance of breaking applications (which suddenly start seeing Unicode strings where none were before). Always using the file system encoding (instead of the default encoding) but leaving the return type might be considered a bug fix. It also might be considered a new feature: you can now do things you couldn't before. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 10:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Sun Oct 22 12:46:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 03:46:19 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 19:12 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 12:46 Message: Logged In: YES user_id=580910 Applied to the trunk in revision 52415. I'm keeping this patch open while waiting for feedback on the backport question that I posted on python-dev. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 12:37 Message: Logged In: YES user_id=21627 The patch is fine, please apply. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 11:29 Message: Logged In: YES user_id=580910 readlink2.patch cleans up the unicode check and adds a documentation update. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 19:48 Message: Logged In: YES user_id=21627 This should be discussed on python-dev. I don't think the change in return type should be backported - it has a real chance of breaking applications (which suddenly start seeing Unicode strings where none were before). Always using the file system encoding (instead of the default encoding) but leaving the return type might be considered a bug fix. It also might be considered a new feature: you can now do things you couldn't before. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 10:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Sun Oct 22 12:47:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 03:47:55 -0700 Subject: [Patches] [ python-Patches-1580872 ] Duplicated declaration of PyCallable_Check Message-ID: Patches item #1580872, was opened at 2006-10-20 00:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Duplicated declaration of PyCallable_Check Initial Comment: [forwarded from http://bugs.debian.org/388713] "the other declaration is found in object.h. The problem is a bit annoying for us, as we use Python in an environment where we wish to consider warnings as errors to be fixed." ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 12:47 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52416 and r52417. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580872&group_id=5470 From noreply at sourceforge.net Sun Oct 22 12:55:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 03:55:57 -0700 Subject: [Patches] [ python-Patches-1560695 ] Exec stacks in python 2.5 Message-ID: Patches item #1560695, was opened at 2006-09-18 14:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Exec stacks in python 2.5 Initial Comment: Python 2.5 contains executable stacks. Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 12:55 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52418 and r52419. ---------------------------------------------------------------------- Comment By: Chaza (masterdriverz) Date: 2006-09-21 13:51 Message: Logged In: YES user_id=1096685 No, sorry I've badly described the situation in the previous post. This patch explicitly tells GCC to not make the stack executable for Python-2.5c1/Modules/_ctypes/libffi/src/x86/sysv.S , this means that it should execute successfully on a hardened system. Without this patch, GCC guesses (incorrectly) that sysv.o requires an executable stack, and sets it accordingly. This can cause execution to fail if Exec Shield is enabled on hardened systems. Basically its just better practice to explicitly mark whether assembly code needs an executable stack or not, and for the most part, it doesn't. For more info (since I'm not brilliant at explaining this) see: http://people.redhat.com/drepper/nonselsec.pdf (particularly Appendix A and Exec Shield) http://people.redhat.com/drepper/selinux-mem.html http://www.gentoo.org/proj/en/hardened/gnu-stack.xml or drop into #gentoo-hardened on Freenode. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 19:05 Message: Logged In: YES user_id=21627 Ah, so the patch doesn't actually fix that Python 2.5 contains executable stacks. It rather makes it execute successfully on a hardened system. Still, I don't understand what you mean by "Python contains executable stacks". Where does it do so? And what precisely breaks on a hardened system when Python is running on it? ---------------------------------------------------------------------- Comment By: Chaza (masterdriverz) Date: 2006-09-20 13:58 Message: Logged In: YES user_id=1096685 It is probably best summed up here -> http://www.gentoo.org/proj/en/hardened/gnu-stack.xml but put simply, executable stacks don't work on hardened systems. The simplest way to fix them is to explicitly tell gcc to compile libraries without executable stacks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 08:26 Message: Logged In: YES user_id=21627 Can you please elaborate? What is an "executable stack", why does Python have one, why is that bad, and how does your patch fix that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 From noreply at sourceforge.net Sun Oct 22 16:36:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 07:36:07 -0700 Subject: [Patches] [ python-Patches-1574252 ] Add %var% support to ntpath.expandvars Message-ID: Patches item #1574252, was opened at 2006-10-10 06:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Norkus (doubleyewdee) Assigned to: Nobody/Anonymous (nobody) Summary: Add %var% support to ntpath.expandvars Initial Comment: NT variables are passed around as %var% instead of $var or ${var}. Providing support for this gives a seamless user experience for NT users using Python. E.g. os.path.expandvars('%TEMP%') now does what is expected on NT. I updated the docstring, could not find any tests or documentation references in svn for this portion of code. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 16:36 Message: Logged In: YES user_id=21627 josiahcarlson, can you propose a strategy to resolve this all? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-17 00:47 Message: Logged In: YES user_id=341410 See also: http://python.org/sf/796219 and http://python.org/sf/957650 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 From noreply at sourceforge.net Sun Oct 22 19:49:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 10:49:39 -0700 Subject: [Patches] [ python-Patches-1574252 ] Add %var% support to ntpath.expandvars Message-ID: Patches item #1574252, was opened at 2006-10-09 21:45 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Norkus (doubleyewdee) Assigned to: Nobody/Anonymous (nobody) Summary: Add %var% support to ntpath.expandvars Initial Comment: NT variables are passed around as %var% instead of $var or ${var}. Providing support for this gives a seamless user experience for NT users using Python. E.g. os.path.expandvars('%TEMP%') now does what is expected on NT. I updated the docstring, could not find any tests or documentation references in svn for this portion of code. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 10:49 Message: Logged In: YES user_id=341410 I believe that there are two changes that are desireable; the functionality offered in this patch (expansion of %VAR% environment variables), and ~user\subpath expansion. Recursive re-application of variable expansion shouldn't occur. I can merge the two patches that adds the functionality to ntpath.expanduser and ntpath.expandvars . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 07:36 Message: Logged In: YES user_id=21627 josiahcarlson, can you propose a strategy to resolve this all? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-16 15:47 Message: Logged In: YES user_id=341410 See also: http://python.org/sf/796219 and http://python.org/sf/957650 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 From noreply at sourceforge.net Sun Oct 22 23:25:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 14:25:56 -0700 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 13:35 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Kurt B. Kaiser (kbk) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 14:25 Message: Logged In: YES user_id=341410 I've just attached an updated version of the patch to handle expandusers (without recursive environment variable expansion), as well as a variant of http://python.org/sf/1574252 to handle %VAR% style expansions on Windows. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 03:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 03:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 18:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 13:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 13:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 13:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\\Documents and Settings\\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\\bob') '~billy\\bob' >>> ntpath.expanduser('~\\bob') 'C:\\Documents and Settings\\jcarlson\\bob' >>> ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') '~billy\\%TESTING%\\%TESTING1%\\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\\billy' >>> ntpath_patched.expanduser('~billy\\bob') 'C:Documents and Settings\\billy\\bob' >>> ntpath_patched.expanduser('~\\bob') 'C:Documents and Settings\\jcarlson\\bob' >>> ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') 'C:Documents and Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Sun Oct 22 23:28:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 14:28:22 -0700 Subject: [Patches] [ python-Patches-1574252 ] Add %var% support to ntpath.expandvars Message-ID: Patches item #1574252, was opened at 2006-10-09 21:45 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chip Norkus (doubleyewdee) Assigned to: Nobody/Anonymous (nobody) Summary: Add %var% support to ntpath.expandvars Initial Comment: NT variables are passed around as %var% instead of $var or ${var}. Providing support for this gives a seamless user experience for NT users using Python. E.g. os.path.expandvars('%TEMP%') now does what is expected on NT. I updated the docstring, could not find any tests or documentation references in svn for this portion of code. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 14:28 Message: Logged In: YES user_id=341410 I've added a new patch to http://python.org/sf/957650 that adds both the expanduser and expandvars case. The expandvars case is slightly different from what the OP submitted, if only in that it won't mask ValueErrors that don't come from the str.index() call. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 10:49 Message: Logged In: YES user_id=341410 I believe that there are two changes that are desireable; the functionality offered in this patch (expansion of %VAR% environment variables), and ~user\subpath expansion. Recursive re-application of variable expansion shouldn't occur. I can merge the two patches that adds the functionality to ntpath.expanduser and ntpath.expandvars . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 07:36 Message: Logged In: YES user_id=21627 josiahcarlson, can you propose a strategy to resolve this all? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-16 15:47 Message: Logged In: YES user_id=341410 See also: http://python.org/sf/796219 and http://python.org/sf/957650 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 From noreply at sourceforge.net Mon Oct 23 06:25:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Oct 2006 21:25:10 -0700 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 22:35 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Martin v. L?wis (loewis) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 23:25 Message: Logged In: YES user_id=341410 I've just attached an updated version of the patch to handle expandusers (without recursive environment variable expansion), as well as a variant of http://python.org/sf/1574252 to handle %VAR% style expansions on Windows. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 12:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 12:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-15 03:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 22:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 22:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 22:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\\Documents and Settings\\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\\bob') '~billy\\bob' >>> ntpath.expanduser('~\\bob') 'C:\\Documents and Settings\\jcarlson\\bob' >>> ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') '~billy\\%TESTING%\\%TESTING1%\\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\\billy' >>> ntpath_patched.expanduser('~billy\\bob') 'C:Documents and Settings\\billy\\bob' >>> ntpath_patched.expanduser('~\\bob') 'C:Documents and Settings\\jcarlson\\bob' >>> ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') 'C:Documents and Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Oct 24 13:21:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Oct 2006 04:21:29 -0700 Subject: [Patches] [ python-Patches-1583506 ] tarfile.py: 100-char filenames are truncated Message-ID: Patches item #1583506, was opened at 2006-10-24 13:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583506&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: 100-char filenames are truncated Initial Comment: Patch #1484695 applied with rev 45954 introduced an error in the creation of string header fields. The stn() function used to zero-pad strings assumes that a string to be put in an N character field, can be at most N-1 chars long plus a '\0' char. This is wrong. An N char field can store a N char string, the '\0' is left out in this case. The worst effect of this bug is that filenames that are exactly 100 chars long will be silently truncated to 99 chars. Python 2.5 and 2.6 are affected. Attached patch fixes the stn() function and adds a testcase to test_tarfile.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583506&group_id=5470 From noreply at sourceforge.net Tue Oct 24 18:38:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Oct 2006 09:38:22 -0700 Subject: [Patches] [ python-Patches-1583880 ] tarfile.py: better use of TarInfo objects with longnames Message-ID: Patches item #1583880, was opened at 2006-10-24 18:38 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=1583880&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: better use of TarInfo objects with longnames Initial Comment: When a TarInfo object with a long name is added to a TarFile, the .name attribute is garbled during the special processing involved with long names. This is true for both posix and gnu mode and has historical "design" reasons. In posix mode, a long name is split in two. TarInfo's prefix attr gets the first part, the name attr the second one. In gnu mode, a long name is truncated up to LENGTH_NAME (100) chars and stored the TarInfo's name attr. So, if you open a TarFile for writing, add a few files with long names to it and call the getnames() method for that still open file, the names returned are all cut. The getmember() method will not work, because all names have changed. On top of that, if a user adds a TarInfo object to a TarFile it is not copied. So, it is undefined what happens if the user uses the same TarInfo object several times with changed attributes. The problem described in bug #1583537 (now deleted) was partly caused by this. The attached patch makes it possible to use the same TarInfo object several times by copying it in TarFile.addfile(), removes the (undocumented) TarInfo.prefix attr and leaves TarInfo.name alone. I think this should be backported to 2.5 as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&group_id=5470 From noreply at sourceforge.net Tue Oct 24 18:54:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Oct 2006 09:54:41 -0700 Subject: [Patches] [ python-Patches-1583506 ] tarfile.py: 100-char filenames are truncated Message-ID: Patches item #1583506, was opened at 2006-10-24 11:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583506&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: 100-char filenames are truncated Initial Comment: Patch #1484695 applied with rev 45954 introduced an error in the creation of string header fields. The stn() function used to zero-pad strings assumes that a string to be put in an N character field, can be at most N-1 chars long plus a '\0' char. This is wrong. An N char field can store a N char string, the '\0' is left out in this case. The worst effect of this bug is that filenames that are exactly 100 chars long will be silently truncated to 99 chars. Python 2.5 and 2.6 are affected. Attached patch fixes the stn() function and adds a testcase to test_tarfile.py. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-24 16:54 Message: Logged In: YES user_id=849994 Applied in rev. 52431, 52432 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583506&group_id=5470 From noreply at sourceforge.net Wed Oct 25 21:57:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Oct 2006 12:57:50 -0700 Subject: [Patches] [ python-Patches-1583880 ] tarfile.py: better use of TarInfo objects with longnames Message-ID: Patches item #1583880, was opened at 2006-10-24 18:38 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: better use of TarInfo objects with longnames Initial Comment: When a TarInfo object with a long name is added to a TarFile, the .name attribute is garbled during the special processing involved with long names. This is true for both posix and gnu mode and has historical "design" reasons. In posix mode, a long name is split in two. TarInfo's prefix attr gets the first part, the name attr the second one. In gnu mode, a long name is truncated up to LENGTH_NAME (100) chars and stored the TarInfo's name attr. So, if you open a TarFile for writing, add a few files with long names to it and call the getnames() method for that still open file, the names returned are all cut. The getmember() method will not work, because all names have changed. On top of that, if a user adds a TarInfo object to a TarFile it is not copied. So, it is undefined what happens if the user uses the same TarInfo object several times with changed attributes. The problem described in bug #1583537 (now deleted) was partly caused by this. The attached patch makes it possible to use the same TarInfo object several times by copying it in TarFile.addfile(), removes the (undocumented) TarInfo.prefix attr and leaves TarInfo.name alone. I think this should be backported to 2.5 as well. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2006-10-25 21:57 Message: Logged In: YES user_id=642936 I spent some more time on the patch and went a bit further. I moved the _create_gnulong() method from TarFile to TarInfo, so TarInfo.tobuf() is now able to create GNU extensions by itself. The distinction between posix and non-posix mode is very clear in the code now. The TarFile.addfile() method is cleaner as well. The only drawback might be that the _dbg calls ("Created GNU extension ... ") are gone now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&group_id=5470 From noreply at sourceforge.net Wed Oct 25 22:32:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Oct 2006 13:32:29 -0700 Subject: [Patches] [ python-Patches-1584712 ] Tix: subwidget names (bug #1472877) Message-ID: Patches item #1584712, was opened at 2006-10-25 20:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1584712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Kievernagel (mkiever) Assigned to: Martin v. L?wis (loewis) Summary: Tix: subwidget names (bug #1472877) Initial Comment: This patch against the trunk rev. 52442 fixes TixSubWidget.__init__ usage of python subwidget names. Now tix subwidget names returned from _subwidget_name are used. See corresponding bug #1472877: http://sourceforge.net/tracker/index.php? func=detail&aid=1472877&group_id=5470&atid=105470 Tested with the code submitted with the bug and with the tix demo code in 'Demo/tix/tixwidgets.py'. Matthias Kievernagel mkiever at web dot de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1584712&group_id=5470 From qouhal at sysmail.supportteam.net Thu Oct 26 14:35:56 2006 From: qouhal at sysmail.supportteam.net (Kit Spencer) Date: Thu, 26 Oct 2006 14:35:56 +0200 Subject: [Patches] crystallize Message-ID: <4540ABAC.3090705@partisan.org.uk> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061026/9667ac22/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: core.gif Type: image/gif Size: 5672 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061026/9667ac22/attachment.gif From xwcx at netraco.com Thu Oct 26 22:39:06 2006 From: xwcx at netraco.com (Edith Mills) Date: Thu, 26 Oct 2006 22:39:06 +0200 Subject: [Patches] until Message-ID: <45411CEA.7030302@coree-culture.org> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061026/c0e06dc2/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: disappointingly.gif Type: image/gif Size: 10486 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061026/c0e06dc2/attachment-0001.gif From noreply at sourceforge.net Fri Oct 27 08:02:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 23:02:52 -0700 Subject: [Patches] [ python-Patches-1549049 ] Fix for structmember conversion issues Message-ID: Patches item #1549049, was opened at 2006-08-30 06:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549049&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for structmember conversion issues Initial Comment: This patch is for bug# 1545696. Patches created against 2.5c1. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-27 08:02 Message: Logged In: YES user_id=21627 A few comments: - the truncation of float values should not cause a warning. float values will always be truncated (i.e. lose precision) when written to T_FLOAT; there's really no way to avoid that. - that PyObject_HEAD_INIT can sometimes be used is because these initializations occur within the same DLL (pythonxy.dll). It is cross-DLL access to addresses of global variables which Windows doesn't support. - I restored support for passing negative values into T_UINT/T_ULONG ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549049&group_id=5470 From noreply at sourceforge.net Fri Oct 27 08:19:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Oct 2006 23:19:25 -0700 Subject: [Patches] [ python-Patches-1549049 ] Fix for structmember conversion issues Message-ID: Patches item #1549049, was opened at 2006-08-30 06:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549049&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for structmember conversion issues Initial Comment: This patch is for bug# 1545696. Patches created against 2.5c1. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-27 08:19 Message: Logged In: YES user_id=21627 Thanks for the patch. I committed it, with modifications, as r52452 for the trunk, and r52453 for the 2.5 branch. In the 2.5 branch, I removed the warnings. Please review my changes to find out errors I may have made. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-27 08:02 Message: Logged In: YES user_id=21627 A few comments: - the truncation of float values should not cause a warning. float values will always be truncated (i.e. lose precision) when written to T_FLOAT; there's really no way to avoid that. - that PyObject_HEAD_INIT can sometimes be used is because these initializations occur within the same DLL (pythonxy.dll). It is cross-DLL access to addresses of global variables which Windows doesn't support. - I restored support for passing negative values into T_UINT/T_ULONG ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549049&group_id=5470 From noreply at sourceforge.net Fri Oct 27 09:13:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 00:13:54 -0700 Subject: [Patches] [ python-Patches-1567274 ] Enable SSL for smtplib Message-ID: Patches item #1567274, was opened at 2006-09-28 21:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567274&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Monty Taylor (sdirector) Assigned to: Nobody/Anonymous (nobody) Summary: Enable SSL for smtplib Initial Comment: This is related to patch 1282340, which I would like to see merged. Here is the patch again, but this time with changes made to the docs. Please let me know what I can do to move this forward. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-27 09:13 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52458. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 10:46 Message: Logged In: YES user_id=849994 Thanks! I closed the old patch accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567274&group_id=5470 From noreply at sourceforge.net Fri Oct 27 18:44:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 09:44:35 -0700 Subject: [Patches] [ python-Patches-1575506 ] Mailbox will not lock properly after flush() Message-ID: Patches item #1575506, was opened at 2006-10-11 15:56 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philippe Gauthier (deuxpi) >Assigned to: A.M. Kuchling (akuchling) Summary: Mailbox will not lock properly after flush() Initial Comment: The _singlefileMailbox class will try to lock the wrong file object after a flush(), resulting into an operation on a closed file object. The following code should illustrate the bug. See also the attached patch. >>> import mailbox >>> >>> box = mailbox.mbox('mbox') >>> msg = "Subject: sub\n\nbody\n" >>> box.add(msg) 0 >>> box.flush() >>> box.close() >>> >>> box = mailbox.mbox('mbox') >>> box.lock() >>> box.add(msg) 1 >>> box.flush() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/mailbox.py", line 581, in flush _lock_file(new_file, dotlock=False) File "/usr/lib/python2.5/mailbox.py", line 1847, in _lock_file fcntl.lockf(f, fcntl.LOCK_UN) ValueError: I/O operation on closed file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 From noreply at sourceforge.net Fri Oct 27 18:58:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 09:58:10 -0700 Subject: [Patches] [ python-Patches-1575506 ] Mailbox will not lock properly after flush() Message-ID: Patches item #1575506, was opened at 2006-10-11 15:56 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Philippe Gauthier (deuxpi) Assigned to: A.M. Kuchling (akuchling) Summary: Mailbox will not lock properly after flush() Initial Comment: The _singlefileMailbox class will try to lock the wrong file object after a flush(), resulting into an operation on a closed file object. The following code should illustrate the bug. See also the attached patch. >>> import mailbox >>> >>> box = mailbox.mbox('mbox') >>> msg = "Subject: sub\n\nbody\n" >>> box.add(msg) 0 >>> box.flush() >>> box.close() >>> >>> box = mailbox.mbox('mbox') >>> box.lock() >>> box.add(msg) 1 >>> box.flush() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/mailbox.py", line 581, in flush _lock_file(new_file, dotlock=False) File "/usr/lib/python2.5/mailbox.py", line 1847, in _lock_file fcntl.lockf(f, fcntl.LOCK_UN) ValueError: I/O operation on closed file ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 12:58 Message: Logged In: YES user_id=11375 Good catch! I think your analysis and patch are correct, and have applied the changes to the trunk (rev. 52478) and 25-maint (rev. 52479). Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1575506&group_id=5470 From noreply at sourceforge.net Fri Oct 27 19:14:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 10:14:33 -0700 Subject: [Patches] [ python-Patches-1574068 ] urllib2 - Fix line breaks in authorization headers Message-ID: Patches item #1574068, was opened at 2006-10-09 17:40 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Scott Dial (geekmug) >Assigned to: A.M. Kuchling (akuchling) Summary: urllib2 - Fix line breaks in authorization headers Initial Comment: urllib2 uses the wrong base64 encode function from the base64 library. This patch corrects that. Original bug report from "The Doctor What" I found a bug in urllib2's handling of basic HTTP authentication. urllib2 uses the base64.encodestring() method to encode the username:password. The problem is that base64.encodestring() adds newlines to wrap the encoded characters at the 76th column. This produces bogus request headers like this: ---------->8---------cut---------8<---------------- GET /some/url HTTP/1.1 Host: some.host Accept-Encoding: identity Authorization: Basic cmVhbGx5bG9uZ3VzZXJuYW1lOmFuZXZlbmxvbmdlcnBhc3N3b3JkdGhhdGdvZXNvbmFuZG9uYW5k b25hbmRvbmFuZG9u User-agent: some-agent ---------->8---------cut---------8<---------------- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 13:14 Message: Logged In: YES user_id=11375 Good fix -- applied to the trunk (rev. 52481) and 25-maint (rev. 52482). Thanks for the patch and for the bug report! ---------------------------------------------------------------------- Comment By: Christian H?ltje (docwhat) Date: 2006-10-10 10:00 Message: Logged In: YES user_id=267 Cool! I'm glad my bug report helped. :-) ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-10-09 20:33 Message: Logged In: YES user_id=383208 Ah yes, you are correct that urllib has the same problem. I have attached a patch to correct all of those instances as well. It is note-worthy that the one usage of decodestring in urllib is correct (as it is decoding the body of the response and should reasonably expect to see newlines in that encoding). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-10-09 20:13 Message: Logged In: YES user_id=261020 urllib should also be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574068&group_id=5470 From noreply at sourceforge.net Fri Oct 27 19:55:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 10:55:00 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 15:43 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 13:54 Message: Logged In: YES user_id=11375 Would it simplify matters if CGIHTTPServer used the subprocess module, which tries to provide a platform-independent interface? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From noreply at sourceforge.net Fri Oct 27 19:57:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 10:57:24 -0700 Subject: [Patches] [ python-Patches-1529018 ] Move firewall warning to "about" menu Message-ID: Patches item #1529018, was opened at 2006-07-26 10:13 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529018&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Tal Einat (taleinat) >Assigned to: Kurt B. Kaiser (kbk) Summary: Move firewall warning to "about" menu Initial Comment: This patch addresses the point brought up in the following post on IDLE-dev by Gregor Lingl. I support this change and nobody raised an objection. " The firewall warning message in the Pythonshell window was introduced in Python 2.3 (IDLE 1.0 or something similar?) I remember well the problems, which have been occurred then, and to which it was the answer. (If I remember correctly I was involved in the discussion thread which led to the introduction of that message.) Since more than three years I've used IDLE on many different systems and I didn't encounter a single Firewall warning since then. (It seems that firewalls nowadays are not offended by the use of 127.0.0.1) Therefore, and because the message is long and ugly, I'd like to suggest to delete it from the Python Shell window and - if considered necessary - for instance to put it into the IDLE Help - "About IDLE" submenu or in a special IDLE-Firewall warning submenu of IDLE-Help. Please observe that it pops up thousands of times and it's read at most once. Additional remark (about my personal interest): I have to do a lot of IDLE-screenshots for a textbook on programming and I really don't like it to occur on all those screenshots. " ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529018&group_id=5470 From noreply at sourceforge.net Fri Oct 27 20:15:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 11:15:29 -0700 Subject: [Patches] [ python-Patches-1503717 ] Tiny patch to stop make spam Message-ID: Patches item #1503717, was opened at 2006-06-09 16:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Chris AtLee (catlee) >Assigned to: A.M. Kuchling (akuchling) Summary: Tiny patch to stop make spam Initial Comment: It's always bothered me that python's Makefile outputs: case $MAKEFLAGS in \ *-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 Maybe it does this for a good reason I don't know about :) In case there isn't, here's a one-line patch to fix it. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 14:15 Message: Logged In: YES user_id=11375 Seems like a reasonable change; applied to the trunk in rev.52484. Thanks! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-09 16:44 Message: Logged In: YES user_id=849994 I'm very much for this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503717&group_id=5470 From noreply at sourceforge.net Fri Oct 27 21:52:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 12:52:39 -0700 Subject: [Patches] [ python-Patches-1585966 ] modulefinder changes for py3k Message-ID: Patches item #1585966, was opened at 2006-10-27 21: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=1585966&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: modulefinder changes for py3k Initial Comment: modulefinder and tests for py3k. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1585966&group_id=5470 From noreply at sourceforge.net Fri Oct 27 22:40:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 13:40:17 -0700 Subject: [Patches] [ python-Patches-1552024 ] unparse.py decorator support Message-ID: Patches item #1552024, was opened at 2006-09-04 14:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552024&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Adal Chiriliuc (adalx) >Assigned to: Georg Brandl (gbrandl) Summary: unparse.py decorator support Initial Comment: I've added decorator output support to /Demo/parser/unparse.py. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-27 20:40 Message: Logged In: YES user_id=849994 Thanks for the patch! Committed as rev. 52488, 52489 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552024&group_id=5470 From noreply at sourceforge.net Sat Oct 28 01:06:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 16:06:16 -0700 Subject: [Patches] [ python-Patches-1585966 ] modulefinder changes for py3k Message-ID: Patches item #1585966, was opened at 2006-10-27 15:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1585966&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: modulefinder changes for py3k Initial Comment: modulefinder and tests for py3k. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-10-27 19:06 Message: Logged In: YES user_id=6380 Thanks! Applied as-is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1585966&group_id=5470 From noreply at sourceforge.net Sat Oct 28 01:32:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 16:32:39 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-30 21:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-10-27 19:32 Message: Logged In: YES user_id=6380 Checked in as r52491. I'm keeping this open awaiting a patch for the compiler package. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-10-09 18:22 Message: Logged In: YES user_id=595483 The new patch that I am uploading fixes the Grammar problem - originally I made mistake not allowing *vararg after keyword only argument. The python compiler package doesn't work now, but everything else should work now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-15 13:13 Message: Logged In: YES user_id=6380 I see. The Grammar should simply make the NAME after the '*' optional. Shouldn't be too hard to fix should it? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 03:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-13 17:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-11 15:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-07 13:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 01:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Sat Oct 28 01:58:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 16:58:29 -0700 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 19:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-28 01:58 Message: Logged In: YES user_id=21627 I think this code can be added to the standard library. Can somebody please provide documentation changes, and also a test suite (as far as reasonable)? Also, Mark: Are you willing to sign a contributor form, at http://www.python.org/psf/contrib/ ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2005-01-12 05:50 Message: Logged In: YES user_id=994239 Sorry for the delayed response; I've been out of town for a while. I understand the point about being able to create threads as needed using asynchat/asyncore. However, if there is no advantage to using the SocketServer framework, why is it there? Is it just for backward compatibility? There are a number of modules in the standard library that use the SocketServer framework. Is an effort being made to rewrite all of them to use asynchat/asyncore? Or are these modules simply grandfathered in, even though no new SocketServer modules are being accepted? In any case, for anyone that might be interested, here's a new version of BaseSMTPServer with the following changes: * Fixed a few incorrect SMTP reply codes. * Imrproved EOF handling. Please let me know what you thinlk. Thanks! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-12-18 21:08 Message: Logged In: YES user_id=366566 Regarding blocking process_message implementations: there really is no issue here. If a blocking operation needs to be performed, then a thread can be created inside process_message. Nothing is gained by starting a thread any earlier than this. Arguably, it is even a loss since it is more computationally and resource intensive to do so. Support for blocking message processing therefore does not seem to be sufficient reason for including this module. Are there other advantages? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-10 08:36 Message: Logged In: YES user_id=341410 It still has a couple tabs, but I don't believe that is a big deal. I think it fits in with the standard SocketServer framework, and that it would make sense to add it, but I don't have any authority to make decisions. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-10 07:40 Message: Logged In: YES user_id=994239 Here's a new version of BaseSMTPServer with the following changes: * Added lots of documentation. * Changed code style to conform with PEP 8. * Added allow_host() method. * Added smtp_NOOP() method. * Improved interface to process_message() and access-control methods. Please let me know what you think. Thanks! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 23:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 23:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-07 08:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 10:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 10:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 08:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sat Oct 28 04:26:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 19:26:07 -0700 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 10:55 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-27 19:26 Message: Logged In: YES user_id=33168 If Mark is a Google employee and Google has rights to this code, it would be covered under the existing Google contrib agreement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-27 16:58 Message: Logged In: YES user_id=21627 I think this code can be added to the standard library. Can somebody please provide documentation changes, and also a test suite (as far as reasonable)? Also, Mark: Are you willing to sign a contributor form, at http://www.python.org/psf/contrib/ ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2005-01-11 20:50 Message: Logged In: YES user_id=994239 Sorry for the delayed response; I've been out of town for a while. I understand the point about being able to create threads as needed using asynchat/asyncore. However, if there is no advantage to using the SocketServer framework, why is it there? Is it just for backward compatibility? There are a number of modules in the standard library that use the SocketServer framework. Is an effort being made to rewrite all of them to use asynchat/asyncore? Or are these modules simply grandfathered in, even though no new SocketServer modules are being accepted? In any case, for anyone that might be interested, here's a new version of BaseSMTPServer with the following changes: * Fixed a few incorrect SMTP reply codes. * Imrproved EOF handling. Please let me know what you thinlk. Thanks! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-12-18 12:08 Message: Logged In: YES user_id=366566 Regarding blocking process_message implementations: there really is no issue here. If a blocking operation needs to be performed, then a thread can be created inside process_message. Nothing is gained by starting a thread any earlier than this. Arguably, it is even a loss since it is more computationally and resource intensive to do so. Support for blocking message processing therefore does not seem to be sufficient reason for including this module. Are there other advantages? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-09 23:36 Message: Logged In: YES user_id=341410 It still has a couple tabs, but I don't believe that is a big deal. I think it fits in with the standard SocketServer framework, and that it would make sense to add it, but I don't have any authority to make decisions. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-09 22:40 Message: Logged In: YES user_id=994239 Here's a new version of BaseSMTPServer with the following changes: * Added lots of documentation. * Changed code style to conform with PEP 8. * Added allow_host() method. * Added smtp_NOOP() method. * Improved interface to process_message() and access-control methods. Please let me know what you think. Thanks! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 14:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-06 23:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 01:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 01:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-05 23:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sat Oct 28 05:41:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Oct 2006 20:41:31 -0700 Subject: [Patches] [ python-Patches-1057417 ] New BaseSMTPServer module Message-ID: Patches item #1057417, was opened at 2004-10-30 13:55 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark D. Roth (mdr0) Assigned to: Nobody/Anonymous (nobody) Summary: New BaseSMTPServer module Initial Comment: A new module that provides an SMTP server base class, derived from the SocketServer class. The class in this module does not implement a fully functional SMTP server; it simply provides a framework that subclasses can use to build their own special-purpose SMTP servers. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-10-27 23:41 Message: Logged In: YES user_id=366566 The code in smtp_DATA isn't factored to allow subclasses to limit the amount of data received. As is, the server is vulnerable to a memory exhaustion attack, since it doesn't implement any kind of limit on the number of lines buffered in memory. It should at least provide a hook for this, even if it still doesn't enforce any limits. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-27 22:26 Message: Logged In: YES user_id=33168 If Mark is a Google employee and Google has rights to this code, it would be covered under the existing Google contrib agreement. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-27 19:58 Message: Logged In: YES user_id=21627 I think this code can be added to the standard library. Can somebody please provide documentation changes, and also a test suite (as far as reasonable)? Also, Mark: Are you willing to sign a contributor form, at http://www.python.org/psf/contrib/ ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2005-01-11 23:50 Message: Logged In: YES user_id=994239 Sorry for the delayed response; I've been out of town for a while. I understand the point about being able to create threads as needed using asynchat/asyncore. However, if there is no advantage to using the SocketServer framework, why is it there? Is it just for backward compatibility? There are a number of modules in the standard library that use the SocketServer framework. Is an effort being made to rewrite all of them to use asynchat/asyncore? Or are these modules simply grandfathered in, even though no new SocketServer modules are being accepted? In any case, for anyone that might be interested, here's a new version of BaseSMTPServer with the following changes: * Fixed a few incorrect SMTP reply codes. * Imrproved EOF handling. Please let me know what you thinlk. Thanks! ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-12-18 15:08 Message: Logged In: YES user_id=366566 Regarding blocking process_message implementations: there really is no issue here. If a blocking operation needs to be performed, then a thread can be created inside process_message. Nothing is gained by starting a thread any earlier than this. Arguably, it is even a loss since it is more computationally and resource intensive to do so. Support for blocking message processing therefore does not seem to be sufficient reason for including this module. Are there other advantages? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-10 02:36 Message: Logged In: YES user_id=341410 It still has a couple tabs, but I don't believe that is a big deal. I think it fits in with the standard SocketServer framework, and that it would make sense to add it, but I don't have any authority to make decisions. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-10 01:40 Message: Logged In: YES user_id=994239 Here's a new version of BaseSMTPServer with the following changes: * Added lots of documentation. * Changed code style to conform with PEP 8. * Added allow_host() method. * Added smtp_NOOP() method. * Improved interface to process_message() and access-control methods. Please let me know what you think. Thanks! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 17:20 Message: Logged In: YES user_id=341410 Hrm, nevemind, I just noticed mdr0's post. I'll leave the rest up to someone who has the authority to make decisions. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-07 17:11 Message: Logged In: YES user_id=341410 Re: features Aside from NOOP (which is easily added), the provided BaseSMTPServer seems to offer the same amount of functionality as smtpd (ignoring DebuggingServer, PureProxy and MailmanProxy, which are trivially borrowed from smtpd). Re: What's the benefit... Someone who wanted to use a synchronous SMTP server would have one available. I think that we should probably wait until the original author answers how this relates to smtpd.py, and perhaps decide then. ---------------------------------------------------------------------- Comment By: Mark D. Roth (mdr0) Date: 2004-11-07 02:11 Message: Logged In: YES user_id=994239 Yes, I am aware of smtpd.py. My understanding is (although please correct me if I'm wrong) that the asyncore/asynchat framework will not be able to service network clients if the found_terminator() method performs an operation that blocks. The BaseSMTPServer class doesn't suffer from that problem, because it's threaded. If you're interested in integrating this module, I'd be happy to clean it up to conform with the Python style guidelines, add documentation, and implement the allow_host() method. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 04:43 Message: Logged In: YES user_id=92689 I just wanted to check whether the author _knows_ smtpd.py, since he doesn't mention it. Maybe I should put it more bluntly: What's the benefit of having an incompatible, less featureful, threaded version of smtpd.py in the library? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-11-06 04:19 Message: Logged In: YES user_id=341410 1) Agreed completely. 2) smtpd.py is written using the asynchat/asyncore framework. This uses the single/multi-threaded/forked SocketServer.TCPServer framework (various protocols have both an asynchronous and synchronous version in the standard library). Other comments: 3) I also think documentation for this module is necessary, as is a 3rd party review of the code and error messages. 4) SSL/TLS support should also be included, along with a reasonable assortment of EHLO, HELP, etc., though smtpd also should gain such support, so this is not a deal-breaker. 5) Perhaps smtpd should gain allow_sender() and allow_recipient() methods, and both should gain allow_host()*. *proper implementations of the above 3 allow_(sender|recipient|host) methods (with either framework) would be sufficient to do temporary hostname blacklisting on remote hosts trying to brute-force a local account listing. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-11-06 02:40 Message: Logged In: YES user_id=92689 1) If you're contributing code, it should follow the style guide (PEP 8) 2) How does this work relate to smtpd.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1057417&group_id=5470 From noreply at sourceforge.net Sat Oct 28 18:39:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Oct 2006 09:39:15 -0700 Subject: [Patches] [ python-Patches-1586315 ] no wraparound for enumerate() Message-ID: Patches item #1586315, was opened at 2006-10-28 16: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=1586315&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: no wraparound for enumerate() Initial Comment: This patch enhances enumerate() in two ways: * first, an optional start argument is added, which will be the first index * second, the index does not wrap around at sys.maxint, but will continue using long integers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586315&group_id=5470 From noreply at sourceforge.net Sat Oct 28 20:12:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Oct 2006 11:12:29 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 15:33 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini <yotamm at mellanox.co.il> sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-10-28 20:12 Message: Logged In: YES user_id=21627 I have update the patch (mmap3.diff) for the current trunk (52498). I've reviewed and tested the Windows implementation, and found the original patch to be incorrect: For MapViewOfFile, instead of passing the size, offset+size must be passed. I also extended it to support 64-bit offsets on a 64-bit system (64-bit offsets on a 32-bit system still aren't supported). I have doubts about the changes to find and tell: why is it good that it includes the offset? In particular, for find, I think it should return the index in the buffer, not the offset in the file. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-12-08 20:01 Message: Logged In: YES user_id=22624 Recent posts deal mainly about with size checks against stat() call. But the main issue here is the support for offset in mmap()ping. I wonder what is the status of this so it would become part of the official release. If nobody cares to implement and test it for MS-Windows, let's have it for Linux/Unix only. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-15 15:07 Message: Logged In: YES user_id=11375 The device driver check is now committed to CVS, both the trunk and 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 22:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 15:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 05:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 19:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 16:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 16:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 05:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 19:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 19:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 19:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 18:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 01:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 22:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-28 01:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 16:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply at sourceforge.net Sat Oct 28 20:29:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Oct 2006 11:29:54 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 06:33 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini <yotamm at mellanox.co.il> sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-28 11:29 Message: Logged In: YES user_id=341410 I agree. In the majority of use-cases that I would consider, offset into the current mmap object would be more useful than into the file. If the mmap has information about its offset in the file, then the user could easily get the file offset. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-28 11:12 Message: Logged In: YES user_id=21627 I have update the patch (mmap3.diff) for the current trunk (52498). I've reviewed and tested the Windows implementation, and found the original patch to be incorrect: For MapViewOfFile, instead of passing the size, offset+size must be passed. I also extended it to support 64-bit offsets on a 64-bit system (64-bit offsets on a 32-bit system still aren't supported). I have doubts about the changes to find and tell: why is it good that it includes the offset? In particular, for find, I think it should return the index in the buffer, not the offset in the file. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-12-08 11:01 Message: Logged In: YES user_id=22624 Recent posts deal mainly about with size checks against stat() call. But the main issue here is the support for offset in mmap()ping. I wonder what is the status of this so it would become part of the official release. If nobody cares to implement and test it for MS-Windows, let's have it for Linux/Unix only. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-15 06:07 Message: Logged In: YES user_id=11375 The device driver check is now committed to CVS, both the trunk and 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 13:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 06:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 20:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 10:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 07:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 07:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 20:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 11:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 10:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 10:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 10:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 09:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 16:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 13:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-27 16:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 07:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply at sourceforge.net Sat Oct 28 23:46:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Oct 2006 14:46:53 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 16:33 Message generated for change (Comment added) made by yotam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini <yotamm at mellanox.co.il> sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2006-10-28 23:46 Message: Logged In: YES user_id=22624 I am not sure I am following all arguments. But a major motivation for having an offset parameter, is to allow for mapping a segment of a huge file. A file could have a size which is too large for memory mapping. But one may need to map just a 'small' segment of a well known offset address. By the way, my experience in this case was in Linux only. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-28 20:29 Message: Logged In: YES user_id=341410 I agree. In the majority of use-cases that I would consider, offset into the current mmap object would be more useful than into the file. If the mmap has information about its offset in the file, then the user could easily get the file offset. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-28 20:12 Message: Logged In: YES user_id=21627 I have update the patch (mmap3.diff) for the current trunk (52498). I've reviewed and tested the Windows implementation, and found the original patch to be incorrect: For MapViewOfFile, instead of passing the size, offset+size must be passed. I also extended it to support 64-bit offsets on a 64-bit system (64-bit offsets on a 32-bit system still aren't supported). I have doubts about the changes to find and tell: why is it good that it includes the offset? In particular, for find, I think it should return the index in the buffer, not the offset in the file. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-12-08 21:01 Message: Logged In: YES user_id=22624 Recent posts deal mainly about with size checks against stat() call. But the main issue here is the support for offset in mmap()ping. I wonder what is the status of this so it would become part of the official release. If nobody cares to implement and test it for MS-Windows, let's have it for Linux/Unix only. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-15 16:07 Message: Logged In: YES user_id=11375 The device driver check is now committed to CVS, both the trunk and 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 23:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 16:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 06:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 20:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 17:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 17:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 06:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 21:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 20:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 19:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 02:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-30 00:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-28 03:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 17:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply at sourceforge.net Sat Oct 28 23:54:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Oct 2006 14:54:54 -0700 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 06:33 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini <yotamm at mellanox.co.il> sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-28 14:54 Message: Logged In: YES user_id=341410 Right. The question that Martin had was if you have some mmap that has been mapped some offset into the large file, and you do mmap.find(...), do you return an offset relative to the file on disk, or relative to the mmap? So if I have m = mmap.mmap(..., startoffset=1024, length=1024), and I do m.find('X'), do I get some value -1...1023 inclusive (-1 for not found), or do I get some value 1024...2047 or -1? I think it only makes sense to return -1...1023, so that the return for .find() and other operations are relative to the mmap, not the file. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2006-10-28 14:46 Message: Logged In: YES user_id=22624 I am not sure I am following all arguments. But a major motivation for having an offset parameter, is to allow for mapping a segment of a huge file. A file could have a size which is too large for memory mapping. But one may need to map just a 'small' segment of a well known offset address. By the way, my experience in this case was in Linux only. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-28 11:29 Message: Logged In: YES user_id=341410 I agree. In the majority of use-cases that I would consider, offset into the current mmap object would be more useful than into the file. If the mmap has information about its offset in the file, then the user could easily get the file offset. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-28 11:12 Message: Logged In: YES user_id=21627 I have update the patch (mmap3.diff) for the current trunk (52498). I've reviewed and tested the Windows implementation, and found the original patch to be incorrect: For MapViewOfFile, instead of passing the size, offset+size must be passed. I also extended it to support 64-bit offsets on a 64-bit system (64-bit offsets on a 32-bit system still aren't supported). I have doubts about the changes to find and tell: why is it good that it includes the offset? In particular, for find, I think it should return the index in the buffer, not the offset in the file. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-12-08 11:01 Message: Logged In: YES user_id=22624 Recent posts deal mainly about with size checks against stat() call. But the main issue here is the support for offset in mmap()ping. I wonder what is the status of this so it would become part of the official release. If nobody cares to implement and test it for MS-Windows, let's have it for Linux/Unix only. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-15 06:07 Message: Logged In: YES user_id=11375 The device driver check is now committed to CVS, both the trunk and 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 13:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 06:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-26 20:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 10:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 07:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 07:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-22 20:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 11:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 10:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 10:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 10:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 09:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-09 16:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-29 13:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-27 16:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 07:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply at sourceforge.net Sun Oct 29 00:15:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Oct 2006 15:15:10 -0700 Subject: [Patches] [ python-Patches-1557890 ] missing imports ctypes in documentation examples Message-ID: Patches item #1557890, was opened at 2006-09-13 05:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Thomas Heller (theller) Summary: missing imports ctypes in documentation examples Initial Comment: The attached patch fixes a couple of missing imports in ctypes documentation examples. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 15:15 Message: Logged In: YES user_id=33168 Thanks for the patch. I think WinError is meant to be a user defined error. There isn't one in ctypes that I saw. So I left that part of the patch out. Instead of adding an import, I used UINT which was already imported and conformed to the prototype given above. Committed revision 52515. (2.5) Committed revision 52514. (2.6) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 From noreply at sourceforge.net Sun Oct 29 10:16:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Oct 2006 01:16:30 -0800 Subject: [Patches] [ python-Patches-1583880 ] tarfile.py: better use of TarInfo objects with longnames Message-ID: Patches item #1583880, was opened at 2006-10-24 16:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Lars Gust?bel (gustaebel) >Assigned to: Georg Brandl (gbrandl) Summary: tarfile.py: better use of TarInfo objects with longnames Initial Comment: When a TarInfo object with a long name is added to a TarFile, the .name attribute is garbled during the special processing involved with long names. This is true for both posix and gnu mode and has historical "design" reasons. In posix mode, a long name is split in two. TarInfo's prefix attr gets the first part, the name attr the second one. In gnu mode, a long name is truncated up to LENGTH_NAME (100) chars and stored the TarInfo's name attr. So, if you open a TarFile for writing, add a few files with long names to it and call the getnames() method for that still open file, the names returned are all cut. The getmember() method will not work, because all names have changed. On top of that, if a user adds a TarInfo object to a TarFile it is not copied. So, it is undefined what happens if the user uses the same TarInfo object several times with changed attributes. The problem described in bug #1583537 (now deleted) was partly caused by this. The attached patch makes it possible to use the same TarInfo object several times by copying it in TarFile.addfile(), removes the (undocumented) TarInfo.prefix attr and leaves TarInfo.name alone. I think this should be backported to 2.5 as well. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-29 09:16 Message: Logged In: YES user_id=849994 Committed as rev. 52524, 52525 (2.5). ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-10-25 19:57 Message: Logged In: YES user_id=642936 I spent some more time on the patch and went a bit further. I moved the _create_gnulong() method from TarFile to TarInfo, so TarInfo.tobuf() is now able to create GNU extensions by itself. The distinction between posix and non-posix mode is very clear in the code now. The TarFile.addfile() method is cleaner as well. The only drawback might be that the _dbg calls ("Created GNU extension ... ") are gone now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&group_id=5470 From noreply at sourceforge.net Sun Oct 29 10:25:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Oct 2006 01:25:04 -0800 Subject: [Patches] [ python-Patches-1564981 ] tarfile depends on undocumented behaviour Message-ID: Patches item #1564981, was opened at 2006-09-25 10:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564981&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Seo Sanghyeon (sanxiyn) >Assigned to: Georg Brandl (gbrandl) Summary: tarfile depends on undocumented behaviour Initial Comment: CPython currently treats an argument to int() or long() when base is specified as null-terminated strings, but this isn't documented AFAIK. i.e. int('0777\0', 8) works. tarfile depends on this behaviour, which breaks IronPython 1.0. Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-29 09:25 Message: Logged In: YES user_id=849994 This was already fixed otherwise. Thanks for the patch though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564981&group_id=5470 From noreply at sourceforge.net Sun Oct 29 10:28:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Oct 2006 01:28:14 -0800 Subject: [Patches] [ python-Patches-1494140 ] Documentation for new Struct object Message-ID: Patches item #1494140, was opened at 2006-05-24 09:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for new Struct object Initial Comment: The performance enhancements to the struct module (patch #1493701) are implemented by having a Struct object, which is a compiled structure. This text file documents these new struct objects. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-29 09:28 Message: Logged In: YES user_id=849994 What's the status of this? It should have been in 2.5 final... ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-02 07:38 Message: Logged In: YES user_id=849994 New/renamed functions need a \versionadded/changed. For StructObjects, I'd suggest a sentence like "Struct objects are new in version 2.5" at the top of the section. There's no explanation how to create a Struct object. The constructor must be explained, preferably on the module overview page. Isn't the type name "Struct"? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-07-30 17:33 Message: Logged In: YES user_id=671362 > Does this patch still need to be updated for pack_to() I suppose so and hence updated my patch. (1) document pack_into(pack_to is renamed to pack_into). (2) document pack_into/pack_from as module functions too(just like re module) As for the function name change, I've already updated "what's new in 2.5" in r50985. I guess the patch is ready to be applied. Reviews are appreciated. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 19:28 Message: Logged In: YES user_id=11375 Does this patch still need to be updated for pack_to(), or can it just be applied? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-07-10 17:26 Message: Logged In: YES user_id=671362 Patch for the TeX style doc. Bob, can you work on updating the main section right after 2.5 b2? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-26 13:05 Message: Logged In: YES user_id=139309 We're going to need to revise this patch some more to document the new pack_to function (for Martin Blais' hotbuf work) Additionally we'll probably also want to revise the main struct documentation to talk about bounds checking and avoiding the creation of long objects. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 14:32 Message: Logged In: YES user_id=139309 That's clearly a typo. I've attached a new version of the patch that removes those two letters. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-24 21:03 Message: Logged In: YES user_id=764593 Shouldn't self.size be the number of bytes required to *pack * the structure? The number required to *unpack* seems like it ought to include tuple overhead and such... ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 15:35 Message: Logged In: YES user_id=139309 New patch attached, fixed unpack documentation, added unpack_from method. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 14:54 Message: Logged In: YES user_id=139309 Hold up on this patch, I need to revise it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 From noreply at sourceforge.net Sun Oct 29 19:44:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Oct 2006 10:44:13 -0800 Subject: [Patches] [ python-Patches-1586791 ] better error msgs for some TypeErrors Message-ID: Patches item #1586791, was opened at 2006-10-29 18: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=1586791&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: better error msgs for some TypeErrors Initial Comment: This includes the wrong type for some objects' TypeErrors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 From noreply at sourceforge.net Mon Oct 30 12:39:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Oct 2006 03:39:16 -0800 Subject: [Patches] [ python-Patches-1587139 ] cookielib: lock acquire/release try..finally protected Message-ID: Patches item #1587139, was opened at 2006-10-30 12: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=1587139&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib: lock acquire/release try..finally protected Initial Comment: Almost all code between lock.acquire and .relase in cookielib was unprotected by a try..finally bracket. I suspect some deadlocks here to have to do with that. This patch against latest version (2.5) in SVN corrects it. Another minor change request: at the end of cookielib.py these 2 special CookieJar-modules are just imported without being referenced/used in cookielib: from _LWPCookieJar import LWPCookieJar, lwp_cookie_str from _MozillaCookieJar import MozillaCookieJar Maybe that should be removed from cookielib in order to further reduce the slow import and leave the (rarely used) import to the user (as with BSDJar etc. too ...) robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587139&group_id=5470 From noreply at sourceforge.net Tue Oct 31 06:05:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Oct 2006 21:05:25 -0800 Subject: [Patches] [ python-Patches-1587674 ] Patch for #1586414 to avoid fragmentation on Windows Message-ID: Patches item #1587674, was opened at 2006-10-31 05:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1586414 to avoid fragmentation on Windows Initial Comment: Add a call to file.truncate() to inform Windows of the size of the target file in makefile(). This helps guide cluster allocation in NTFS to avoid fragmentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 From eajcz at indigenes-republique.org Tue Oct 31 14:25:54 2006 From: eajcz at indigenes-republique.org (Timothy Deleon) Date: Tue, 31 Oct 2006 13:25:54 +0000 Subject: [Patches] rake Message-ID: <45474EE2.9040603@contemporary-paintings.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061031/4eebf7d9/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: consortia.gif Type: image/gif Size: 5041 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061031/4eebf7d9/attachment.gif From noreply at sourceforge.net Tue Oct 31 17:18:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Oct 2006 08:18:41 -0800 Subject: [Patches] [ python-Patches-1586315 ] no wraparound for enumerate() Message-ID: Patches item #1586315, was opened at 2006-10-28 11:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586315&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) >Assigned to: Raymond Hettinger (rhettinger) Summary: no wraparound for enumerate() Initial Comment: This patch enhances enumerate() in two ways: * first, an optional start argument is added, which will be the first index * second, the index does not wrap around at sys.maxint, but will continue using long integers. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-31 11:18 Message: Logged In: YES user_id=80475 Guido already rejected having an optional start parameter. And without that, there is no need for wrap-around logic. I would like to keep enumerate simple, fast, and as clean as a whistle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586315&group_id=5470