From noreply at sourceforge.net Fri Dec 1 19:45:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 10:45:29 -0800 Subject: [ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes Message-ID: Bugs item #1607041, was opened at 2006-12-01 10:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 From noreply at sourceforge.net Fri Dec 1 20:22:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 11:22:19 -0800 Subject: [ python-Bugs-1607061 ] Incorrect use of 'int' and 'long' descriptions Message-ID: Bugs item #1607061, was opened at 2006-12-01 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&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: 5 Private: No Submitted By: John (johnjsal) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect use of 'int' and 'long' descriptions Initial Comment: On the main page for the array module, the following is in the type code chart: 'I' unsigned int long 2 'l' signed long int 4 Should 'long' and 'int' be switched in the second column? Thanks, John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&group_id=5470 From noreply at sourceforge.net Fri Dec 1 20:40:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 11:40:05 -0800 Subject: [ python-Bugs-1607061 ] Incorrect use of 'int' and 'long' descriptions Message-ID: Bugs item #1607061, was opened at 2006-12-01 19:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&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: Invalid Priority: 5 Private: No Submitted By: John (johnjsal) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect use of 'int' and 'long' descriptions Initial Comment: On the main page for the array module, the following is in the type code chart: 'I' unsigned int long 2 'l' signed long int 4 Should 'long' and 'int' be switched in the second column? Thanks, John ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-01 19:40 Message: Logged In: YES user_id=849994 Originator: NO No, the second column refers to the Python type used. This is "int" for signed longs, because this is the base type for a Python int, and "long" for unsigned ints, because on most 32-bit platforms int == long and therefore an unsigned int is outside the range of a Python int. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607061&group_id=5470 From noreply at sourceforge.net Fri Dec 1 22:06:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 13:06:47 -0800 Subject: [ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes Message-ID: Bugs item #1607041, was opened at 2006-12-01 13:45 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 16:06 Message: Logged In: YES user_id=366566 Originator: NO Why should it work that way? c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes". If you want c.waitUntil(9 oclock), maybe that would be a good API addition, but it definitely should be a separate method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 From noreply at sourceforge.net Fri Dec 1 22:10:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 13:10:01 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 00:43 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 16:10 Message: Logged In: YES user_id=366566 Originator: NO This seems to work fine for me: >>> s = socket.socket(socket.AF_INET6) >>> s.bind(('ip6-localhost', 8091)) >>> s.getsockname() ('::1', 8091, 0, 0) >>> exarkun at charm:~$ grep ip6-localhost /etc/hosts ::1 ip6-localhost ip6-loopback exarkun at charm:~$ Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't listening on ::1, only 127.1? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-29 16:35 Message: Logged In: YES user_id=3060 Originator: YES host is 'localhost' port is 2947 What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 16:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 01:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Fri Dec 1 22:11:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 13:11:22 -0800 Subject: [ python-Bugs-1598083 ] Top-level exception handler writes to stdout unsafely Message-ID: Bugs item #1598083, was opened at 2006-11-16 18:50 Message generated for change (Settings changed) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598083&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: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 6 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Top-level exception handler writes to stdout unsafely Initial Comment: When an exception reaches the top frame and is displayed by the exception handler, they are handled by formatting them to stderr. This involves a series of calls to PyFile_WriteString, either directly from PyErr_Display or indirectly through PyTraceBack_Print. Few, if any, of these PyFile_WriteString calls have their result checked for error. Worse, PyFile_WriteString itself does not check the return value of fputs(). So, for example, with a signal handler installed, a signal received while a traceback is being printed can result in the traceback _not_ being printed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598083&group_id=5470 From noreply at sourceforge.net Fri Dec 1 22:57:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 13:57:48 -0800 Subject: [ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes Message-ID: Bugs item #1607041, was opened at 2006-12-01 10:45 Message generated for change (Comment added) made by hashstat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. ---------------------------------------------------------------------- >Comment By: BC (hashstat) Date: 2006-12-01 13:57 Message: Logged In: YES user_id=939959 Originator: YES Apparently my description wasn't as clear as I thought. I don't care about the clock times in the example. They were only used to illustrate the point. What I do care about is that if a use c.wait(3600) ("wait 60 minutes"), then my thread should wake up in roughly 60 minutes without regard to changes in the system clock. With the current Condition implementation, no matter what timeout is used, setting the system clock ahead reduces or eliminates the wait while setting the system clock back increases the wait. So if the clock is set back one hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return in an hour and 1 microsecond. Is this the way it should work? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 13:06 Message: Logged In: YES user_id=366566 Originator: NO Why should it work that way? c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes". If you want c.waitUntil(9 oclock), maybe that would be a good API addition, but it definitely should be a separate method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 From noreply at sourceforge.net Fri Dec 1 23:18:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 14:18:07 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 05:43 Message generated for change (Comment added) made by esr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- >Comment By: Eric S. Raymond (esr) Date: 2006-12-01 22:18 Message: Logged In: YES user_id=3060 Originator: YES >Are you sure this isn't a local misconfiguration? I'm not. I didn't see it happen. I suggest you email Mr. Berger and ask him. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 21:10 Message: Logged In: YES user_id=366566 Originator: NO This seems to work fine for me: >>> s = socket.socket(socket.AF_INET6) >>> s.bind(('ip6-localhost', 8091)) >>> s.getsockname() ('::1', 8091, 0, 0) >>> exarkun at charm:~$ grep ip6-localhost /etc/hosts ::1 ip6-localhost ip6-loopback exarkun at charm:~$ Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't listening on ::1, only 127.1? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-29 21:35 Message: Logged In: YES user_id=3060 Originator: YES host is 'localhost' port is 2947 What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 21:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 06:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Fri Dec 1 23:35:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 14:35:02 -0800 Subject: [ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes Message-ID: Bugs item #1607041, was opened at 2006-12-01 10:45 Message generated for change (Comment added) made by hashstat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. ---------------------------------------------------------------------- >Comment By: BC (hashstat) Date: 2006-12-01 14:35 Message: Logged In: YES user_id=939959 Originator: YES I submitted patch# 1607149 to add checking for clock variations in the wait method when called with a timeout. ---------------------------------------------------------------------- Comment By: BC (hashstat) Date: 2006-12-01 13:57 Message: Logged In: YES user_id=939959 Originator: YES Apparently my description wasn't as clear as I thought. I don't care about the clock times in the example. They were only used to illustrate the point. What I do care about is that if a use c.wait(3600) ("wait 60 minutes"), then my thread should wake up in roughly 60 minutes without regard to changes in the system clock. With the current Condition implementation, no matter what timeout is used, setting the system clock ahead reduces or eliminates the wait while setting the system clock back increases the wait. So if the clock is set back one hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return in an hour and 1 microsecond. Is this the way it should work? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 13:06 Message: Logged In: YES user_id=366566 Originator: NO Why should it work that way? c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes". If you want c.waitUntil(9 oclock), maybe that would be a good API addition, but it definitely should be a separate method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 From noreply at sourceforge.net Fri Dec 1 23:48:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 14:48:10 -0800 Subject: [ python-Bugs-1597404 ] sqlite timestamp converter bug (floating point) Message-ID: Bugs item #1597404, was opened at 2006-11-16 02:00 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Salib (msalib_ita) Assigned to: Gerhard H?ring (ghaering) Summary: sqlite timestamp converter bug (floating point) Initial Comment: The pysqlite code in Python 2.5 has a bug. This bug also exists in the upstream pysqlite2 release, but their tracker is down so I cannot submit it there. The bug is as follows: if you insert a datetime object into a sqlite database and then try to retrieve the object, you will (in some cases) get a datetime instance with a slightly smaller value for the microseconds field. This bug occurs because pysqlite is doing pointless floating point conversions. I describe two fixes and an extra test case below. This bug is real. I have observed it in the wild. The test set for my application can trigger this bug about once every 20 runs. This is what happens: * pysqlite includes an adapter and converter function so that datetime objects can transparently be inserted and retrieved from a sqlite database column of type timestamp. * When inserting a datetime object, pysqlite's adapter will insert the isoformat() value of the object. * When retrieving, pysqlite will take the iso formatted string representation of the datetime object and convert it into an actual datetime object. This conversion is buggy. * Check out line 71 of Lib/sqlite3/dbapi2.py. The code is: microseconds = int(float("0." + timepart_full[1]) * 1000000) And that is where the bug is. This code takes an integer value, converts it into a float (implicitly dividing by 1000000, then multiplies that by 1000000 and takes the integer part. For most values, that process gives the result you expect. For some values however, like 510241, that process gives slightly smaller values because of floating point rounding. There are two possible fixes: 1. The simple fix is to just do rounding properly by using this line in place of the previous line: microseconds = int(0.5 + (float("0." + timepart_full[1]) * 1000000)) This will eliminate the bug. 2. The better fix (IMHO) is to stop playing games with floating point numbers. There is absolutely no reason to introduce floats into this computation. The datetime object stores microseconds as an integer value and it gets written to the database as a stringified integer value. Taking apart that string and converting it into an integer is a lossless operation. My preferred fix is thus: microseconds = int(timepart_full[1]) This will eliminate the bug and it has the benefit of being shorter as well. I've attached a patch with my preferred fix as well as an extra test in the pysqlite test suite (Lib/sqlite3/test/types.py). You can run the pysqlite test suite by running Lib/sqlite3/test/types.py. Note that without my fix, the test that I added (DateTimeTests.CheckDateTimeSubSecondsFloatingPoint) will fail but with my fix it will pass. ---------------------------------------------------------------------- >Comment By: Gerhard H?ring (ghaering) Date: 2006-12-01 23:48 Message: Logged In: YES user_id=163326 Originator: NO Fixed in upstream pysqlite. Leaving open until next merge to Python's sqlite3 module. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 07:18 Message: Logged In: YES user_id=21627 Originator: NO Gerhard, can you please take a look? If not, unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&group_id=5470 From noreply at sourceforge.net Fri Dec 1 23:50:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 14:50:09 -0800 Subject: [ python-Bugs-1607041 ] Condition.wait timeout fails when system clock changes Message-ID: Bugs item #1607041, was opened at 2006-12-01 13:45 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: Condition.wait timeout fails when system clock changes Initial Comment: If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example: import threading c = threading.Condition() c.acquire() try: ... c.wait(3600.0) ... finally: c.release() Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour. Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 17:50 Message: Logged In: YES user_id=366566 Originator: NO Yes, I misunderstood. Please disregard my comments. :) ---------------------------------------------------------------------- Comment By: BC (hashstat) Date: 2006-12-01 17:35 Message: Logged In: YES user_id=939959 Originator: YES I submitted patch# 1607149 to add checking for clock variations in the wait method when called with a timeout. ---------------------------------------------------------------------- Comment By: BC (hashstat) Date: 2006-12-01 16:57 Message: Logged In: YES user_id=939959 Originator: YES Apparently my description wasn't as clear as I thought. I don't care about the clock times in the example. They were only used to illustrate the point. What I do care about is that if a use c.wait(3600) ("wait 60 minutes"), then my thread should wake up in roughly 60 minutes without regard to changes in the system clock. With the current Condition implementation, no matter what timeout is used, setting the system clock ahead reduces or eliminates the wait while setting the system clock back increases the wait. So if the clock is set back one hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return in an hour and 1 microsecond. Is this the way it should work? ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 16:06 Message: Logged In: YES user_id=366566 Originator: NO Why should it work that way? c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes". If you want c.waitUntil(9 oclock), maybe that would be a good API addition, but it definitely should be a separate method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607041&group_id=5470 From noreply at sourceforge.net Sat Dec 2 02:09:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Dec 2006 17:09:58 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 10:29 Message generated for change (Comment added) made by mad-marty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&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: Python Library Group: None >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Pieter Zieschang (mad-marty) Assigned to: Vinay Sajip (vsajip) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- >Comment By: Pieter Zieschang (mad-marty) Date: 2006-12-02 02:09 Message: Logged In: YES user_id=1269426 Originator: YES Hi, after some investigation, I think I found the source. Just add 'import psyco; psyco.full()' to test.py aufer imports and you get the same problem with your example. It seems, logging is not compatible with the way psyco creates proxy functions. Could be that sys._getframe returns something different. - just a guess But it works with the old logging. Is there any other information you may want ? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-11-30 10:18 Message: Logged In: YES user_id=308438 Originator: NO I need more information. For example (N.B. lines may wrap, please adjust if copy/pasting the code below): #-- test.py import module import logging logging.basicConfig(level=logging.DEBUG, format="%(relativeCreated)-6d %(module)s %(filename)s %(lineno)d - %(message)s") logging.getLogger("test").debug("Test starting, about to start thread...") threads = module.start() for t in threads: t.join() logging.getLogger("test").debug("All done.") #-- test.py ends #-- module.py import logging import threading import random import time class MyThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break class MyOtherThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break def start(): t1 = MyThread(name="Thread One") t2 = MyOtherThread(name="Thread Two") t1.start() t2.start() return t1, t2 #-- module.py ends When I run test, I get the following output: 15 test test.py 7 - Test starting, about to start thread... 15 module module.py 11 - Running in thread: Thread One 15 module module.py 22 - Running in thread: Thread Two 327 module module.py 11 - Running in thread: Thread One 343 module module.py 22 - Running in thread: Thread Two 655 module module.py 11 - Running in thread: Thread One 780 module module.py 22 - Running in thread: Thread Two 1000 module module.py 11 - Running in thread: Thread One 1546 module module.py 22 - Running in thread: Thread Two 1890 module module.py 11 - Running in thread: Thread One 2046 module module.py 11 - Running in thread: Thread One 2218 module module.py 22 - Running in thread: Thread Two 2562 module module.py 22 - Running in thread: Thread Two 3187 test test.py 11 - All done. This is the expected output. Python version used: ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 13:02 Message: Logged In: YES user_id=1269426 Originator: YES Checked again and found that the bug was introduced with Python 2.4.2. Last correctly working version is python-2.4.1.msi. ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 10:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Sun Dec 3 11:18:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 02:18:37 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 10:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 11:25:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 02:25:31 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 10:18 Message generated for change (Comment added) made by etaoinbe2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library Group: Python 2.5 Status: Open Resolution: None >Priority: 9 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- >Comment By: joe (etaoinbe2) Date: 2006-12-03 10:25 Message: Logged In: YES user_id=1249766 Originator: YES this is on windows, the faulting address is always the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 11:34:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 02:34:16 -0800 Subject: [ python-Bugs-1606092 ] csv module broken for unicode Message-ID: Bugs item #1606092, was opened at 2006-11-30 15:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: M.-A. Lemburg (lemburg) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 11:34 Message: Logged In: YES user_id=21627 Originator: NO Are you willing to fix it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&group_id=5470 From noreply at sourceforge.net Sun Dec 3 11:36:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 02:36:37 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library >Group: Python 2.4 Status: Open Resolution: None >Priority: 5 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 11:36 Message: Logged In: YES user_id=21627 Originator: NO AFAICT, this might be a bug in wxpython also, or in some other extension module you are using. Can you give any example code that allows to reproduce the crash? Without that, there is little chance that the problem can be fixed. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 11:25 Message: Logged In: YES user_id=1249766 Originator: YES this is on windows, the faulting address is always the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 13:44:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 04:44:16 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-04 04:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 13:44 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. Where in the spec does it say that the first value should be used? On the contrary, the spec seems to say that the last value should be used: # Instances of the same path and name will overwrite each other, # with the latest instance taking precedence. So if that's what the current module does, there is no bug. ---------------------------------------------------------------------- Comment By: Viraj Alankar (valankar) Date: 2005-12-04 23:46 Message: Logged In: YES user_id=107970 Heh I guess that means I should try to write a patch. Might be a good learning experience for me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 19:16 Message: Logged In: YES user_id=261020 OK, I see. I agree that it's a bug, but I'm undecided whether the existing behaviour should be fixed. It's true that clients are supposed to (and do) send the most specific cookie last, so this bug could cause servers to see the cookie from, eg path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. However, module Cookie is old and stable, and a patch might break servers expecting the current behaviour. I *suppose* such breakage is fairly unlikely, so I wouldn't object to a patch. I certainly don't see anybody objecting to a patch to add a new method to allow access to multiple cookies of the same name without altering the existing dict interface (repr() could change, but not eg. .get()). Either way, I suspect a patch is only likely to appear from somebody who is actually using such cookies, though :-) ---------------------------------------------------------------------- Comment By: Viraj Alankar (valankar) Date: 2005-12-04 17:07 Message: Logged In: YES user_id=107970 Basically, sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs say that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. Another example might be: Cookie: mycookie=foo; path=bar Cookie: mycookie=foo; path=baz In this case there should be 2 cookies with the name 'mycookie'. The uniqueness is determined by the different paths. Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 16:52 Message: Logged In: YES user_id=261020 I don't get it: >>> import Cookie >>> c = Cookie.SimpleCookie() >>> c.load("foo=bar; bar=baz") >>> c Where's the problem? In general, don't pay too much attention to that standard, BTW: http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Sun Dec 3 13:54:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 04:54:59 -0800 Subject: [ python-Bugs-1606092 ] csv module broken for unicode Message-ID: Bugs item #1606092, was opened at 2006-11-30 15:46 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) >Assigned to: Nobody/Anonymous (nobody) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-12-03 13:54 Message: Logged In: YES user_id=38388 Originator: NO It should be easy to provide a wrapper class which implements the above in plain Python. However, if noone volunteers to write such code, it's not going to happen. I've found that the builtin csv module is not flexible enough to deal with the often broken CSV data you typically find in practice, so perhaps adding a pure Python implementation which works with Unicode might prove to be a better approach. Unassigning the report, since I don't have time for this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 11:34 Message: Logged In: YES user_id=21627 Originator: NO Are you willing to fix it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&group_id=5470 From noreply at sourceforge.net Sun Dec 3 14:10:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 05:10:47 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 10:18 Message generated for change (Comment added) made by etaoinbe2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- >Comment By: joe (etaoinbe2) Date: 2006-12-03 13:10 Message: Logged In: YES user_id=1249766 Originator: YES I have tried to insulate the problem to a particular part of the code but that did not work out. I have currently no small program that shows this only the complete integrated app shows this. If you have a build with assembler listings enabled then you might be able to find where that address is ? Or can I get a debugbuild so that a meaningfull stacktrace can be produced? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 10:36 Message: Logged In: YES user_id=21627 Originator: NO AFAICT, this might be a bug in wxpython also, or in some other extension module you are using. Can you give any example code that allows to reproduce the crash? Without that, there is little chance that the problem can be fixed. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 10:25 Message: Logged In: YES user_id=1249766 Originator: YES this is on windows, the faulting address is always the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 14:56:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 05:56:15 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 14:56 Message: Logged In: YES user_id=21627 Originator: NO For a debug build, you need debug versions of everything, including wxPython. If you have VS.NET 2003 or 2005, you should be able to produce such binaries yourself. For Python, you need to follow the instructions in PCBuild/readme.txt. I don't know how wxPython is built. You might also be successful with creating a release build that has debug information enabled; in that case, it is sufficient to rebuild Python. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 14:10 Message: Logged In: YES user_id=1249766 Originator: YES I have tried to insulate the problem to a particular part of the code but that did not work out. I have currently no small program that shows this only the complete integrated app shows this. If you have a build with assembler listings enabled then you might be able to find where that address is ? Or can I get a debugbuild so that a meaningfull stacktrace can be produced? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 11:36 Message: Logged In: YES user_id=21627 Originator: NO AFAICT, this might be a bug in wxpython also, or in some other extension module you are using. Can you give any example code that allows to reproduce the crash? Without that, there is little chance that the problem can be fixed. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 11:25 Message: Logged In: YES user_id=1249766 Originator: YES this is on windows, the faulting address is always the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 17:49:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 08:49:26 -0800 Subject: [ python-Bugs-1372650 ] Cookie and multiple names Message-ID: Bugs item #1372650, was opened at 2005-12-04 03:47 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-12-03 16:49 Message: Logged In: YES user_id=261020 Originator: NO loewis: In the Netscape cookie protocol (which is specified approximately, though ambiguously, and incorrectly in places, by cookie_spec.html), cookies sent from client to server in the Cookie: header do not include the path (neither as "path=/foo/bar", nor even as "$path=/foo/bar"). In valankar's first example of 2005-12-04 16:07, the two cookies must be interpreted as having different paths (if they do not have different paths, the client is not behaving correctly). See the section titled "Second Example transaction sequence:" in cookie_spec.html for an example of this. So, the part of cookie_spec.html you quote is not relevant (in fact, it refers to client behaviour, not server behaviour -- though it doesn't say so explicitly!). BTW, I said earlier: "clients are supposed to (and do) send the most specific cookie last". That's backwards: in fact, clients send the most specific (longest-path) cookie first. Cookie.py always ignores all but the last cookie (it overwrites the first), so it will only store the least-specific cookie, so my point stands. Also note that valankar's second example of 2005-12-04 16:07 is incorrect (unless he meant Set-Cookie: instead of Cookie:): the Cookie header should never contain path cookie-attributes (see penultimate paragraph of this comment, and perhaps more clearly, method cookielib.CookieJar._cookie_attrs()). By "cookie-attribute" I mean a string of the form "=", i.e. the same thing as represented by instances of Cookie.Morsel . AFAIK (not 100% sure here) when several cookies are returned, none of the cookie standards defines which cookie servers should or should not look at, so Cookie.py should probably make all of the cookies available through some interface. If it chooses to only provide one cookie (as it does), it would seem that a good choice would be the first cookie in the string passed to .load(), since that should be the one with the longest path. Cookie.py instead takes the last cookie (probably by accident). That's not good, but I'm unsure whether it should be changed, since it may break old code. I'm puzzled by Cookie.py's design: First, poor naming: BaseCookie (and therefore a SimpleCookie instance) seems to represent multiple HTTP cookies. Second, BaseCookie.load(string) treats attributes like "path" specially, and I do not understand why. The documentation says you're intended to pass the value of HTTP_COOKIE to that string, but AFAICS, if the client obeys any of the cookie protocols (either the de facto Netscape protocol or any of the RFCs) then HTTP_COOKIE should never contain a string like "; path=x", where x is replaced by any arbitrary string (assuming here that HTTP_COOKIE is always simply the value of the HTTP header named "Cookie", and for simplicity that there are no quoted strings in the Cookie header). Third, BaseCookie does not allow storing several cookies of the same name. As I understand it, this last problem is the one valankar was complaining about. I've always found cookies highly confusing, I must say, so it's always possible I've got something mixed up by now... but I don't think so. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 12:44 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. Where in the spec does it say that the first value should be used? On the contrary, the spec seems to say that the last value should be used: # Instances of the same path and name will overwrite each other, # with the latest instance taking precedence. So if that's what the current module does, there is no bug. ---------------------------------------------------------------------- Comment By: Viraj Alankar (valankar) Date: 2005-12-04 22:46 Message: Logged In: YES user_id=107970 Heh I guess that means I should try to write a patch. Might be a good learning experience for me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 18:16 Message: Logged In: YES user_id=261020 OK, I see. I agree that it's a bug, but I'm undecided whether the existing behaviour should be fixed. It's true that clients are supposed to (and do) send the most specific cookie last, so this bug could cause servers to see the cookie from, eg path '/cgi-bin' instead of from path '/mystuff/cgi-bin'. However, module Cookie is old and stable, and a patch might break servers expecting the current behaviour. I *suppose* such breakage is fairly unlikely, so I wouldn't object to a patch. I certainly don't see anybody objecting to a patch to add a new method to allow access to multiple cookies of the same name without altering the existing dict interface (repr() could change, but not eg. .get()). Either way, I suspect a patch is only likely to appear from somebody who is actually using such cookies, though :-) ---------------------------------------------------------------------- Comment By: Viraj Alankar (valankar) Date: 2005-12-04 16:07 Message: Logged In: YES user_id=107970 Basically, sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs say that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. Another example might be: Cookie: mycookie=foo; path=bar Cookie: mycookie=foo; path=baz In this case there should be 2 cookies with the name 'mycookie'. The uniqueness is determined by the different paths. Thanks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:52 Message: Logged In: YES user_id=261020 I don't get it: >>> import Cookie >>> c = Cookie.SimpleCookie() >>> c.load("foo=bar; bar=baz") >>> c Where's the problem? In general, don't pay too much attention to that standard, BTW: http://wwwsearch.sourceforge.net/ClientCookie/doc.html#standards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 From noreply at sourceforge.net Sun Dec 3 18:28:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 09:28:12 -0800 Subject: [ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often Message-ID: Bugs item #1607951, was opened at 2006-12-03 18:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.Maildir re-reads directory too often Initial Comment: [forwarded from http://bugs.debian.org/401395] Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir. _refresh should stat each of the two directories first to see if they changed. This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&group_id=5470 From noreply at sourceforge.net Sun Dec 3 19:22:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 10:22:27 -0800 Subject: [ python-Bugs-1606092 ] csv module broken for unicode Message-ID: Bugs item #1606092, was opened at 2006-11-30 08:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-12-03 12:22 Message: Logged In: YES user_id=44345 Originator: NO I must admit I don't understand the criticism of the UnicodeReader and UnicodeWriter example classes in the module documentation. Sure, their implementations jump through some hoops, but that's so you don't have to. If you use them as written I believe their API's should be about the same as the csv.reader and csv.writer classes with the added improvement that the reader returns Unicode and the writer accepts Unicode. If your desire is to read and write Unicode why do you care that those objects are encoded using utf-8 in the file? Like Martin asked, are you willing to come up with better examples? Better yet, are you willing to provide a patch for the underlying extension module so it handles Unicode? Hint: I'm fairly certain that if it was trivial it would have been done by now. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-12-03 06:54 Message: Logged In: YES user_id=38388 Originator: NO It should be easy to provide a wrapper class which implements the above in plain Python. However, if noone volunteers to write such code, it's not going to happen. I've found that the builtin csv module is not flexible enough to deal with the often broken CSV data you typically find in practice, so perhaps adding a pure Python implementation which works with Unicode might prove to be a better approach. Unassigning the report, since I don't have time for this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 04:34 Message: Logged In: YES user_id=21627 Originator: NO Are you willing to fix it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&group_id=5470 From noreply at sourceforge.net Sun Dec 3 19:42:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 10:42:01 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 10:18 Message generated for change (Comment added) made by etaoinbe2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- >Comment By: joe (etaoinbe2) Date: 2006-12-03 18:42 Message: Logged In: YES user_id=1249766 Originator: YES I have vs7.0 & 6.0 7.0 does not accept 7.1 project files so try with 6.0 : --------------------Configuration: pythoncore - Win32 Debug-------------------- Build : warning : failed to (or don't know how to) build 'C:\Python-2.5\Modules\structmodule.c' Compiling... exceptions.c fatal error C1083: Cannot open source file: 'C:\Python-2.5\Python\exceptions.c': No such file or directory md5c.c fatal error C1083: Cannot open source file: 'C:\Python-2.5\Modules\md5c.c': No such file or directory structmodule.c fatal error C1083: Cannot open source file: 'C:\Python-2.5\Modules\structmodule.c': No such file or directory Error executing cl.exe. python25_d.dll - 3 error(s), 1 warning(s) Those files are really not there ? So how shall I proceed ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 13:56 Message: Logged In: YES user_id=21627 Originator: NO For a debug build, you need debug versions of everything, including wxPython. If you have VS.NET 2003 or 2005, you should be able to produce such binaries yourself. For Python, you need to follow the instructions in PCBuild/readme.txt. I don't know how wxPython is built. You might also be successful with creating a release build that has debug information enabled; in that case, it is sufficient to rebuild Python. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 13:10 Message: Logged In: YES user_id=1249766 Originator: YES I have tried to insulate the problem to a particular part of the code but that did not work out. I have currently no small program that shows this only the complete integrated app shows this. If you have a build with assembler listings enabled then you might be able to find where that address is ? Or can I get a debugbuild so that a meaningfull stacktrace can be produced? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 10:36 Message: Logged In: YES user_id=21627 Originator: NO AFAICT, this might be a bug in wxpython also, or in some other extension module you are using. Can you give any example code that allows to reproduce the crash? Without that, there is little chance that the problem can be fixed. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 10:25 Message: Logged In: YES user_id=1249766 Originator: YES this is on windows, the faulting address is always the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 19:59:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 10:59:52 -0800 Subject: [ python-Bugs-1607759 ] segfault in python24.dll Message-ID: Bugs item #1607759, was opened at 2006-12-03 10:18 Message generated for change (Comment added) made by etaoinbe2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: joe (etaoinbe2) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in python24.dll Initial Comment: In my app that uses wxpython2.7 extensively I get regularly following segfault (null pointer exception): AppName: python.exe AppVer: 0.0.0.0 ModName: python24.dll ModVer: 2.4.150.1012 Offset: 00030f33 I have been unable to pinpoint it to a certain location of the program. :( ---------------------------------------------------------------------- >Comment By: joe (etaoinbe2) Date: 2006-12-03 18:59 Message: Logged In: YES user_id=1249766 Originator: YES It is a real pity open source software requires closed source compilers ! trying to build with 7.0 gives: -------------------------------- ------ Build started: Project: pythoncore, Configuration: Debug Win32 ------ Compiling... zipimport.c yuvconvert.c xxsubtype.c weakrefobject.c unicodeobject.c unicodectype.c typeobject.c tupleobject.c traceback.c tokenizer.c timemodule.c threadmodule.c thread.c sysmodule.c symtablemodule.c symtable.c structseq.c structmember.c stropmodule.c stringobject.c sliceobject.c signalmodule.c shamodule.c sha512module.c \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(146) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(146) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(146) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(146) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(159) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(159) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(159) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(159) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(159) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(159) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(159) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(160) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(160) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(160) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(160) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(160) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(160) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(160) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(161) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(161) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(161) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(161) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(161) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(161) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(161) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(162) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(162) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(162) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : error C2146: syntax error : missing ')' before identifier 'L' \Python-2.5\Modules\sha512module.c(162) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(162) : error C2144: syntax error : '' should be preceded by '' \Python-2.5\Modules\sha512module.c(162) : error C2143: syntax error : missing ')' before 'identifier' \Python-2.5\Modules\sha512module.c(162) : error C2059: syntax error : 'bad suffix on number' \Python-2.5\Modules\sha512module.c(162) : fatal error C1013: compiler limit : too many open parentheses sha256module.c setobject.c rotatingtree.c rgbimgmodule.c rangeobject.c pythonrun.c Python-ast.c pystrtod.c pystate.c pyfpe.c pyarena.c posixmodule.c parsetok.c parsermodule.c parser.c operator.c obmalloc.c object.c node.c mystrtoul.c mysnprintf.c myreadline.c multibytecodec.c msvcrtmodule.c moduleobject.c modsupport.c mmapmodule.c methodobject.c metagrammar.c md5module.c md5.c mathmodule.c marshal.c main.c longobject.c listobject.c listnode.c itertoolsmodule.c iterobject.c intobject.c importdl.c import.c imageop.c grammar1.c grammar.c graminit.c getversion.c getplatform.c getpathp.c getopt.c getmtime.c getcopyright.c getcompiler.c getargs.c genobject.c gcmodule.c future.c funcobject.c frozen.c frameobject.c floatobject.c firstsets.c fileobject.c exceptions.c errors.c errnomodule.c enumobject.c dynload_win.c dl_nt.c dictobject.c Build cancelled Build log was saved at "file://c:\Python-2.5\PCbuild\x86-temp-debug\pythoncore\BuildLog.htm" pythoncore - 95 error(s), 0 warning(s) ---------------------- Done ---------------------- ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 18:42 Message: Logged In: YES user_id=1249766 Originator: YES I have vs7.0 & 6.0 7.0 does not accept 7.1 project files so try with 6.0 : --------------------Configuration: pythoncore - Win32 Debug-------------------- Build : warning : failed to (or don't know how to) build 'C:\Python-2.5\Modules\structmodule.c' Compiling... exceptions.c fatal error C1083: Cannot open source file: 'C:\Python-2.5\Python\exceptions.c': No such file or directory md5c.c fatal error C1083: Cannot open source file: 'C:\Python-2.5\Modules\md5c.c': No such file or directory structmodule.c fatal error C1083: Cannot open source file: 'C:\Python-2.5\Modules\structmodule.c': No such file or directory Error executing cl.exe. python25_d.dll - 3 error(s), 1 warning(s) Those files are really not there ? So how shall I proceed ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 13:56 Message: Logged In: YES user_id=21627 Originator: NO For a debug build, you need debug versions of everything, including wxPython. If you have VS.NET 2003 or 2005, you should be able to produce such binaries yourself. For Python, you need to follow the instructions in PCBuild/readme.txt. I don't know how wxPython is built. You might also be successful with creating a release build that has debug information enabled; in that case, it is sufficient to rebuild Python. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 13:10 Message: Logged In: YES user_id=1249766 Originator: YES I have tried to insulate the problem to a particular part of the code but that did not work out. I have currently no small program that shows this only the complete integrated app shows this. If you have a build with assembler listings enabled then you might be able to find where that address is ? Or can I get a debugbuild so that a meaningfull stacktrace can be produced? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 10:36 Message: Logged In: YES user_id=21627 Originator: NO AFAICT, this might be a bug in wxpython also, or in some other extension module you are using. Can you give any example code that allows to reproduce the crash? Without that, there is little chance that the problem can be fixed. ---------------------------------------------------------------------- Comment By: joe (etaoinbe2) Date: 2006-12-03 10:25 Message: Logged In: YES user_id=1249766 Originator: YES this is on windows, the faulting address is always the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607759&group_id=5470 From noreply at sourceforge.net Sun Dec 3 21:15:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 12:15:20 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 05:43 Message generated for change (Comment added) made by rjbsourceforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- Comment By: Robert J. Berger (rjbsourceforge) Date: 2006-12-03 20:15 Message: Logged In: YES user_id=29744 Originator: NO I will try to get a simple example that reproduces it. Unfortunately I don't have access to the system that was doing it today. I will try to get something in the bug report in the next day or so. But basically if /etc/hosts had localhost defined as ::1 the connect method failded, when I set localhost to 127.0.0.1 the connect worked. Other non-python (c++) processes were able to access the socket when localhost was set to ::1 This was on Fedora Core 6 with the latest patches at that time. ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-12-01 22:18 Message: Logged In: YES user_id=3060 Originator: YES >Are you sure this isn't a local misconfiguration? I'm not. I didn't see it happen. I suggest you email Mr. Berger and ask him. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 21:10 Message: Logged In: YES user_id=366566 Originator: NO This seems to work fine for me: >>> s = socket.socket(socket.AF_INET6) >>> s.bind(('ip6-localhost', 8091)) >>> s.getsockname() ('::1', 8091, 0, 0) >>> exarkun at charm:~$ grep ip6-localhost /etc/hosts ::1 ip6-localhost ip6-loopback exarkun at charm:~$ Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't listening on ::1, only 127.1? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-29 21:35 Message: Logged In: YES user_id=3060 Originator: YES host is 'localhost' port is 2947 What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 21:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 06:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Sun Dec 3 23:39:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 14:39:38 -0800 Subject: [ python-Bugs-1602378 ] Incorrect docs for bisect_left Message-ID: Bugs item #1602378, was opened at 2006-11-24 09:07 Message generated for change (Comment added) made by eloff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&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: 5 Private: No Submitted By: Daniel Eloff (eloff) Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect docs for bisect_left Initial Comment: Quote: Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell. >>> from bisect import * >>> l = [1,2,3,3,3,4,5] >>> bisect_left(l,3) 2 >>> l[2:] [3, 3, 3, 4, 5] It should be changed to read "i points at the leftmost x already there" -Dan ---------------------------------------------------------------------- >Comment By: Daniel Eloff (eloff) Date: 2006-12-03 14:39 Message: Logged In: YES user_id=730918 Originator: YES That makes more sense, but if that's explained anywhere it was hidden away where I've never discovered it. I would be in favor of you're suggested fix to the line in question. -Dan ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-11-24 11:16 Message: Logged In: YES user_id=31435 Originator: NO The docs are written from the POV that indices in Python point /between/ array elements, which is the easiest way to understand slices, and that there are n+1 non-negative indices that "make obvious sense" in slices of a sequence with n elements: index 0 points "just before" element a[0], and index n "just after" element a[n-1], while for 0 < i < n-1, index i points "just before" element [i] /and/ "just after" element a[i-1]. This is also the sanest way to understand the return value of the bisect functions, which again can return n+1 values given a sequence with n elements. That said, I agree the docs are cryptic if you don't understand that first. I'm not sure this is the best place to explain it. The specific line in question could be "repaired" by saying a[i] is the leftmost x already there, identifying one of the n elements instead of one of the n+1 sequence positions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 From noreply at sourceforge.net Mon Dec 4 04:20:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 3 Dec 2006 19:20:04 -0800 Subject: [ python-Bugs-1579931 ] not configured for tk Message-ID: <200612040320.kB43K46l020999@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1579931, was opened at 2006-10-18 11:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&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.4 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-03 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 02:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 02:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-18 14:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 From noreply at sourceforge.net Mon Dec 4 04:23:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Dec 2006 19:23:04 -0800 Subject: [ python-Bugs-1579931 ] not configured for tk Message-ID: Bugs item #1579931, was opened at 2006-10-18 11:59 Message generated for change (Comment added) made by carlwenrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&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.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. ---------------------------------------------------------------------- >Comment By: Carl Wenrich (carlwenrich) Date: 2006-12-03 19:23 Message: Logged In: YES user_id=1524461 Originator: YES just found out i didn't have the DEVELOPMENT libraries for tcl and tk. got them. it works now. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-12-03 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 02:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 02:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-18 14:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 From noreply at sourceforge.net Mon Dec 4 10:20:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 01:20:44 -0800 Subject: [ python-Feature Requests-1592899 ] "".translate() docs should mention string.maketrans() Message-ID: Feature Requests item #1592899, was opened at 2006-11-08 21:23 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ori Avtalion (salty-horse) Assigned to: Raymond Hettinger (rhettinger) Summary: "".translate() docs should mention string.maketrans() Initial Comment: The translate() documentation at http://docs.python.org/lib/string-methods.html#l2h-268 should mention the string.maketrans helper function. maketrans also mentions "regex.compile" - that should probably be "re.compile" (although it's less readable). re.compile should mention maketrans as well. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 10:20 Message: Logged In: YES user_id=38376 Originator: NO "re.compile should mention maketrans as well" why? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 From noreply at sourceforge.net Mon Dec 4 10:27:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 01:27:55 -0800 Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode groups and block ranges needed Message-ID: Feature Requests item #1528154, was opened at 2006-07-25 06:44 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&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: Regular Expressions Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: gmarketer (gmarketer) Assigned to: Nobody/Anonymous (nobody) Summary: New sequences for Unicode groups and block ranges needed Initial Comment: The special sequences consist of "\" and another character need to be added to RE sintax to simplify the finding of several Unicode classes like: * All uppercase letters * All lowercase letters ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 10:27 Message: Logged In: YES user_id=38376 Originator: NO note that posix uses a special set syntax, [:name:], for this purpose: [:alnum:] [:cntrl:] [:lower:] [:space:] [:alpha:] [:digit:] [:print:] [:upper:] [:blank:] [:graph:] [:punct:] [:xdigit:] adding a new character escape will probably break more existing expressions, but no matter what syntax we chose, this is (micro-)PEP territory. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 12:36 Message: Logged In: YES user_id=21627 If anything, I think Python should implement Unicode TR#18: http://www.unicode.org/unicode/reports/tr18/ This does include the \p notation for property expressions, e.g. \p{Ll} or \p{East Asian Width:Narrow}. We currently don't include the Script property, so \p{Greek} could not be implemented (we can, of course, add support for the script property). I can't find anything in the report that makes \p{IsGreek} valid, so we shouldn't support it. ---------------------------------------------------------------------- Comment By: gmarketer (gmarketer) Date: 2006-07-26 04:06 Message: Logged In: YES user_id=1334865 We need to process several strings in utf-8 and need to use regular expressions to match pattern, for ex.: r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY" We don't know how to implement this logic by our hands. Also, I found this logic implemented in Microsoft dot NET regular expressions: \p{name} Matches any character in the named character class 'name'. Supported names are Unicode groups and block ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc (currency). \P{name} Matches text not included in the named character class 'name'. We need same logic in regular expressions. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-07-25 09:45 Message: Logged In: YES user_id=38388 Could you make your request a little more specific ? We already have catregories in the re module, so adding a few more would be possible (patches are welcome !). However, we do need to know why you need them and whether there are other RE implementations that already have such special matching characters, e.g. the Perl RE implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470 From noreply at sourceforge.net Mon Dec 4 10:28:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 01:28:03 -0800 Subject: [ python-Feature Requests-1528154 ] New sequences for Unicode groups and block ranges needed Message-ID: Feature Requests item #1528154, was opened at 2006-07-25 06:44 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&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: Regular Expressions Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: gmarketer (gmarketer) Assigned to: Nobody/Anonymous (nobody) Summary: New sequences for Unicode groups and block ranges needed Initial Comment: The special sequences consist of "\" and another character need to be added to RE sintax to simplify the finding of several Unicode classes like: * All uppercase letters * All lowercase letters ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 10:28 Message: Logged In: YES user_id=38376 Originator: NO note that posix uses a special set syntax, [:name:], for this purpose: [:alnum:] [:cntrl:] [:lower:] [:space:] [:alpha:] [:digit:] [:print:] [:upper:] [:blank:] [:graph:] [:punct:] [:xdigit:] adding a new character escape will probably break more existing expressions, but no matter what syntax we chose, this is (micro-)PEP territory. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 10:27 Message: Logged In: YES user_id=38376 Originator: NO note that posix uses a special set syntax, [:name:], for this purpose: [:alnum:] [:cntrl:] [:lower:] [:space:] [:alpha:] [:digit:] [:print:] [:upper:] [:blank:] [:graph:] [:punct:] [:xdigit:] adding a new character escape will probably break more existing expressions, but no matter what syntax we chose, this is (micro-)PEP territory. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-10 12:36 Message: Logged In: YES user_id=21627 If anything, I think Python should implement Unicode TR#18: http://www.unicode.org/unicode/reports/tr18/ This does include the \p notation for property expressions, e.g. \p{Ll} or \p{East Asian Width:Narrow}. We currently don't include the Script property, so \p{Greek} could not be implemented (we can, of course, add support for the script property). I can't find anything in the report that makes \p{IsGreek} valid, so we shouldn't support it. ---------------------------------------------------------------------- Comment By: gmarketer (gmarketer) Date: 2006-07-26 04:06 Message: Logged In: YES user_id=1334865 We need to process several strings in utf-8 and need to use regular expressions to match pattern, for ex.: r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY" We don't know how to implement this logic by our hands. Also, I found this logic implemented in Microsoft dot NET regular expressions: \p{name} Matches any character in the named character class 'name'. Supported names are Unicode groups and block ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc (currency). \P{name} Matches text not included in the named character class 'name'. We need same logic in regular expressions. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-07-25 09:45 Message: Logged In: YES user_id=38388 Could you make your request a little more specific ? We already have catregories in the re module, so adding a few more would be possible (patches are welcome !). However, we do need to know why you need them and whether there are other RE implementations that already have such special matching characters, e.g. the Perl RE implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470 From noreply at sourceforge.net Mon Dec 4 18:08:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 09:08:07 -0800 Subject: [ python-Feature Requests-1592899 ] "".translate() docs should mention string.maketrans() Message-ID: Feature Requests item #1592899, was opened at 2006-11-08 22:23 Message generated for change (Comment added) made by salty-horse You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ori Avtalion (salty-horse) Assigned to: Raymond Hettinger (rhettinger) Summary: "".translate() docs should mention string.maketrans() Initial Comment: The translate() documentation at http://docs.python.org/lib/string-methods.html#l2h-268 should mention the string.maketrans helper function. maketrans also mentions "regex.compile" - that should probably be "re.compile" (although it's less readable). re.compile should mention maketrans as well. ---------------------------------------------------------------------- >Comment By: Ori Avtalion (salty-horse) Date: 2006-12-04 19:08 Message: Logged In: YES user_id=854801 Originator: YES >"re.compile should mention maketrans as well" >why? The maketrans doc says: "Return a translation table suitable for passing to translate() or regex.compile()" I don't have any use case for how it's useful to regex.compile. Maybe there is none, and the mention can be removed. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 11:20 Message: Logged In: YES user_id=38376 Originator: NO "re.compile should mention maketrans as well" why? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 From noreply at sourceforge.net Mon Dec 4 18:42:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 09:42:07 -0800 Subject: [ python-Feature Requests-1592899 ] "".translate() docs should mention string.maketrans() Message-ID: Feature Requests item #1592899, was opened at 2006-11-08 21:23 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ori Avtalion (salty-horse) Assigned to: Raymond Hettinger (rhettinger) Summary: "".translate() docs should mention string.maketrans() Initial Comment: The translate() documentation at http://docs.python.org/lib/string-methods.html#l2h-268 should mention the string.maketrans helper function. maketrans also mentions "regex.compile" - that should probably be "re.compile" (although it's less readable). re.compile should mention maketrans as well. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 18:42 Message: Logged In: YES user_id=38376 Originator: NO Aha. The regex documentation says: compile (pattern[, translate]) /.../ The optional argument translate, if present, must be a 256-character string indicating how characters (both of the pattern and of the strings to be matched) are translated before comparing them; the i-th element of the string gives the translation for the character with ASCII code i. This can be used to implement case-insensitive matching; see the casefold data item below. which means that it was indeed useful for regex.compile. afaik, re.compile doesn't support arbitrary mappings, so that reference should be removed. ---------------------------------------------------------------------- Comment By: Ori Avtalion (salty-horse) Date: 2006-12-04 18:08 Message: Logged In: YES user_id=854801 Originator: YES >"re.compile should mention maketrans as well" >why? The maketrans doc says: "Return a translation table suitable for passing to translate() or regex.compile()" I don't have any use case for how it's useful to regex.compile. Maybe there is none, and the mention can be removed. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 10:20 Message: Logged In: YES user_id=38376 Originator: NO "re.compile should mention maketrans as well" why? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 From noreply at sourceforge.net Mon Dec 4 23:34:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 14:34:06 -0800 Subject: [ python-Bugs-1608818 ] Sloppy error checking in listdir() for Posix Message-ID: Bugs item #1608818, was opened at 2006-12-04 17:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1608818&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: Sloppy error checking in listdir() for Posix Initial Comment: In the Linux/Unix (non-Windows / non-OS2) implementation of listdir() in posixmodule.c, a check for errno != 0 is done after the loop. This assumes that errno is only set by readdir() but in fact it's possible for it to be set in PyUnicode_FromEncodedObject() if codecs are used in the conversion (actually that's a separate bug I'll report when I've investigated it futher). To tighten this up, I'd recommend moving the errno != 0 clause in its entirety to just after the readdir() call and possibly resetting errno=0 before the readdir() call so it's clear the error really happened there. I've attached a possible patch for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1608818&group_id=5470 From noreply at sourceforge.net Tue Dec 5 04:08:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Dec 2006 19:08:22 -0800 Subject: [ python-Bugs-1608921 ] PyThread_release_lock with pthreads munges errno Message-ID: Bugs item #1608921, was opened at 2006-12-04 22:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1608921&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: PyThread_release_lock with pthreads munges errno Initial Comment: In normal operation with pthreads when PyThread_release_lock is called and it calls PyThread_acquire_lock in the "sanity check" errno will be set to 11 and left that way. It seems like this should not happen so thread switches don't arbitrarily and w/o much reason alter the program state. I ran into this working on a threaded debugger where a lock is used internally. The debugger I'm writing now saves/restores errno in its tracer but it seems like there is potential for this bug all over the place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1608921&group_id=5470 From noreply at sourceforge.net Tue Dec 5 12:53:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Dec 2006 03:53:19 -0800 Subject: [ python-Bugs-1606092 ] csv module broken for unicode Message-ID: Bugs item #1606092, was opened at 2006-11-30 16:46 Message generated for change (Comment added) made by jettlogic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? ---------------------------------------------------------------------- >Comment By: JettLogic (jettlogic) Date: 2006-12-05 13:53 Message: Logged In: YES user_id=1345991 Originator: YES Anyone know why it uses a C extension? The C code apparently appends fields to a writable byte buffer (so patching for unicode is impossible), reallocated as it grows. How much efficiency is gained by doing that, with its many lines of logic overhead, versus careful use of python strings? For montanaro, the UnicodeWriter with three coding conversions and a StringIO shows there is however much efficiency to be lost. Perhaps lemburg's suggestion of a pure-python re-implementation of _csv is the way to go. It does not look like a fun task, after adding in back-compatibility, benchmarks and tests, and I couldn't commit to it just yet. Are C->Py patches typically accepted? (assume quality code and comparable benchmarks) I'll have to leave it at that. If you leave this open, someone might take it up at some point. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-12-03 20:22 Message: Logged In: YES user_id=44345 Originator: NO I must admit I don't understand the criticism of the UnicodeReader and UnicodeWriter example classes in the module documentation. Sure, their implementations jump through some hoops, but that's so you don't have to. If you use them as written I believe their API's should be about the same as the csv.reader and csv.writer classes with the added improvement that the reader returns Unicode and the writer accepts Unicode. If your desire is to read and write Unicode why do you care that those objects are encoded using utf-8 in the file? Like Martin asked, are you willing to come up with better examples? Better yet, are you willing to provide a patch for the underlying extension module so it handles Unicode? Hint: I'm fairly certain that if it was trivial it would have been done by now. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-12-03 14:54 Message: Logged In: YES user_id=38388 Originator: NO It should be easy to provide a wrapper class which implements the above in plain Python. However, if noone volunteers to write such code, it's not going to happen. I've found that the builtin csv module is not flexible enough to deal with the often broken CSV data you typically find in practice, so perhaps adding a pure Python implementation which works with Unicode might prove to be a better approach. Unassigning the report, since I don't have time for this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 12:34 Message: Logged In: YES user_id=21627 Originator: NO Are you willing to fix it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&group_id=5470 From noreply at sourceforge.net Tue Dec 5 16:10:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Dec 2006 07:10:08 -0800 Subject: [ python-Bugs-1603424 ] subprocess.py (py2.5) wrongly claims py2.2 compatibility Message-ID: Bugs item #1603424, was opened at 2006-11-26 20:07 Message generated for change (Comment added) made by racarr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603424&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Wegener (twegener) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py (py2.5) wrongly claims py2.2 compatibility Initial Comment: >From the comments in subprocess.py (py2.5): # This module should remain compatible with Python 2.2, see PEP 291. However, using it from Python 2.2 gives: NameError: global name 'set' is not defined (set built-in used on line 1005) The subprocess.py in py2.4 was 2.2 compatible. Either the compatibility comment should be removed/amended or compatibility fixed. ---------------------------------------------------------------------- Comment By: Robert Carr (racarr) Date: 2006-12-05 10:10 Message: Logged In: YES user_id=1649655 Originator: NO Index: subprocess.py =================================================================== --- subprocess.py (revision 52918) +++ subprocess.py (working copy) @@ -1004,8 +1004,8 @@ # Close pipe fds. Make sure we don't close the same # fd more than once, or standard fds. - for fd in set((p2cread, c2pwrite, errwrite))-set((0,1,2)): - if fd: os.close(fd) + for fd in (p2cread,c2pwrite,errwrite): + if fd not in (0,1,2): os.close(fd) # Close all other fds, if asked for if close_fds: Fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603424&group_id=5470 From noreply at sourceforge.net Tue Dec 5 16:26:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Dec 2006 07:26:04 -0800 Subject: [ python-Bugs-1593751 ] poor urllib error handling Message-ID: Bugs item #1593751, was opened at 2006-11-09 16:04 Message generated for change (Comment added) made by racarr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&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: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: poor urllib error handling Initial Comment: I set up a simple server that returns an empty response. >>> from socket import * >>> s = socket() >>> s.bind(("", 9999)) >>> while 1: x, c = s.accept(); print c; x.recv(1000); x.close() ... Pointing urllib at this gives a traceback: Python 2.6a0 (trunk:52099M, Oct 3 2006, 09:59:17) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.urlopen('http://localhost:9999/') Traceback (most recent call last): File "", line 1, in File "/home/guido/p/Lib/urllib.py", line 82, in urlopen return opener.open(url) File "/home/guido/p/Lib/urllib.py", line 190, in open return getattr(self, name)(url) File "/home/guido/p/Lib/urllib.py", line 334, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 351, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/home/guido/p/Lib/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/home/guido/p/Lib/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' >>> I can repeat this with 2.2.3 and 2.4.3 as well (don't have 2.3 around for testing). The direct cause of the problem is that h.getfile() on line 329 of urllib.py (in head of trunk) returns None. ---------------------------------------------------------------------- Comment By: Robert Carr (racarr) Date: 2006-12-05 10:26 Message: Logged In: YES user_id=1649655 Originator: NO Fix? Index: urllib.py =================================================================== --- urllib.py (revision 52918) +++ urllib.py (working copy) @@ -895,8 +895,10 @@ def __init__(self, fp): self.fp = fp - self.read = self.fp.read - self.readline = self.fp.readline + try: + self.read = self.fp.read + self.readline = self.fp.readline + except: print "File handler is none" if hasattr(self.fp, "readlines"): self.readlines = self.fp.readlines if hasattr(self.fp, "fileno"): self.fileno = self.fp.fileno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&group_id=5470 From noreply at sourceforge.net Wed Dec 6 04:05:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Dec 2006 19:05:39 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 04:49 Message generated for change (Comment added) made by eloff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-05 19:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 06:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 20:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 05:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Dec 6 07:10:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Dec 2006 22:10:14 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) >Assigned to: Martin v. L?wis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 04:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 15:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 14:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Dec 6 08:29:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Dec 2006 23:29:23 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. L?wis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 08:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 04:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 15:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 14:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Dec 6 10:58:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 01:58:57 -0800 Subject: [ python-Bugs-1609958 ] tarfile archive paths limited to less than 100 chars Message-ID: Bugs item #1609958, was opened at 2006-12-06 10:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Rehberger (frehberg) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile archive paths limited to less than 100 chars Initial Comment: The tarfile-module 0.8 shipped with Python-2.5 fails to handle archive-paths longer than 100 chars, in posix mode and GNU-mode. AFAICS, the path-length limit should be 256 for posix-mode and infinite for GNU-mode. The last tarfile module I know, being able to handle long paths is tarfile-0.7.4. Attached you will find a test-script. The script prints the tarfile.version you are using to console and runs two tests, one for posix-mode up to path-length 256 and a second test for GNU-mode with pathlengths up to 1024. ### ###Testoutput with Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /home/frehberg/tmp/bin/python Tarfile Version: 0.8.0 TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=True) TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=False) ### ###Workarround for Python-2.5 ### (Assuming you are using Linux and Python-2.5 has been installed with prefix /usr/local/) Download tarfile-0.7.4 from http://www.gustaebel.de/lars/tarfile/ and run: ## remove original tarfile-module shipped with ## python2.5 rm -rf /usr/local/lib/python2.5/tarfile.py* ## install tarfile-0.7.4 tar -xvz -C /tmp/ -f /net/linux/pkg/python/tarfile-0.7.4.tar.gz cd /tmp/tarfile-0.7.4/ /usr/local/bin/python2.5 setup.py install ### ###Testoutput with patched Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /usr/local/bin/python Tarfile Version: 0.7.4 Tarfile module (posix=True) is Ok Tarfile module (posix=False) is Ok ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&group_id=5470 From noreply at sourceforge.net Wed Dec 6 16:22:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 07:22:21 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 04:49 Message generated for change (Comment added) made by mikepowers48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. L?wis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 07:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-05 23:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-05 19:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 06:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 20:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 05:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Dec 6 16:56:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 07:56:48 -0800 Subject: [ python-Bugs-1606092 ] csv module broken for unicode Message-ID: Bugs item #1606092, was opened at 2006-11-30 08:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-12-06 09:56 Message: Logged In: YES user_id=44345 Originator: NO > Anyone know why it uses a C extension? Performance. A number of people (among them the authors of the _csv extension and me, a contributor to the Python csv module that fronts it) routinely read and write large (several megabytes) CSV files. We had all had experience with earlier Python-only CSV readers and writers. Their performance was just too poor. If you wrote a new module in Python that's compatible with the existing module -- and performed acceptably -- I see no reason it couldn't replace the current module. There are already a number of test cases. You'd certainly have to embellish them, but if the current set passed that would be a good indication your code was at least on the right track compatibility-wise. There are other reasons to desire a Python-based solution other than Unicode support. It would be much more likely that such a module would work with other Python implementations (e.g., PyPy, IronPython and Jython). Skip ---------------------------------------------------------------------- Comment By: JettLogic (jettlogic) Date: 2006-12-05 05:53 Message: Logged In: YES user_id=1345991 Originator: YES Anyone know why it uses a C extension? The C code apparently appends fields to a writable byte buffer (so patching for unicode is impossible), reallocated as it grows. How much efficiency is gained by doing that, with its many lines of logic overhead, versus careful use of python strings? For montanaro, the UnicodeWriter with three coding conversions and a StringIO shows there is however much efficiency to be lost. Perhaps lemburg's suggestion of a pure-python re-implementation of _csv is the way to go. It does not look like a fun task, after adding in back-compatibility, benchmarks and tests, and I couldn't commit to it just yet. Are C->Py patches typically accepted? (assume quality code and comparable benchmarks) I'll have to leave it at that. If you leave this open, someone might take it up at some point. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-12-03 12:22 Message: Logged In: YES user_id=44345 Originator: NO I must admit I don't understand the criticism of the UnicodeReader and UnicodeWriter example classes in the module documentation. Sure, their implementations jump through some hoops, but that's so you don't have to. If you use them as written I believe their API's should be about the same as the csv.reader and csv.writer classes with the added improvement that the reader returns Unicode and the writer accepts Unicode. If your desire is to read and write Unicode why do you care that those objects are encoded using utf-8 in the file? Like Martin asked, are you willing to come up with better examples? Better yet, are you willing to provide a patch for the underlying extension module so it handles Unicode? Hint: I'm fairly certain that if it was trivial it would have been done by now. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-12-03 06:54 Message: Logged In: YES user_id=38388 Originator: NO It should be easy to provide a wrapper class which implements the above in plain Python. However, if noone volunteers to write such code, it's not going to happen. I've found that the builtin csv module is not flexible enough to deal with the often broken CSV data you typically find in practice, so perhaps adding a pure Python implementation which works with Unicode might prove to be a better approach. Unassigning the report, since I don't have time for this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 04:34 Message: Logged In: YES user_id=21627 Originator: NO Are you willing to fix it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&group_id=5470 From noreply at sourceforge.net Wed Dec 6 19:43:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 10:43:18 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 04:49 Message generated for change (Comment added) made by eloff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. L?wis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 10:43 Message: Logged In: YES user_id=730918 Originator: NO Thanks Martin, I applied the patch. The problem I was having was the IO Error, sorry for being vague. The part I don't understand is I should not have had other threads running (and definately should not have had the logger being used outside the main thread.) Can the problem occur with just one thread? I was running under the debugger in wing, I don't know if that might cause this problem. Anyway if I find out anything else I'll let you know. If you don't hear from me then everything is working great. ---------------------------------------------------------------------- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 07:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-05 23:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-05 19:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 06:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 20:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 05:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Dec 6 19:58:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 10:58:11 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. L?wis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 19:58 Message: Logged In: YES user_id=21627 Originator: NO eloff: It may be that there are different problems that all show the symptom; *this* problem reported here can only occur if you are using multiple threads (atleast for the ValueError; haven't looked into the crash at all). Yes, you can run multiple threads, and yes, you can use logging freely. However, you should not let the main thread just "run off". Instead, you should end your main thread with an explicit .join() operation on all threads it has created; those threads themselves should perform explicit .join() operations on all threads they create. That way, you can guarantee orderly shutdown. threading.py tries to do the joining if you don't, but fails (and the approach it uses is inherently error-prone). ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 19:43 Message: Logged In: YES user_id=730918 Originator: NO Thanks Martin, I applied the patch. The problem I was having was the IO Error, sorry for being vague. The part I don't understand is I should not have had other threads running (and definately should not have had the logger being used outside the main thread.) Can the problem occur with just one thread? I was running under the debugger in wing, I don't know if that might cause this problem. Anyway if I find out anything else I'll let you know. If you don't hear from me then everything is working great. ---------------------------------------------------------------------- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 16:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 08:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 04:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 15:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 14:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Wed Dec 6 23:22:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 14:22:14 -0800 Subject: [ python-Bugs-1609958 ] tarfile archive paths limited to less than 100 chars Message-ID: Bugs item #1609958, was opened at 2006-12-06 09:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&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: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Frank Rehberger (frehberg) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile archive paths limited to less than 100 chars Initial Comment: The tarfile-module 0.8 shipped with Python-2.5 fails to handle archive-paths longer than 100 chars, in posix mode and GNU-mode. AFAICS, the path-length limit should be 256 for posix-mode and infinite for GNU-mode. The last tarfile module I know, being able to handle long paths is tarfile-0.7.4. Attached you will find a test-script. The script prints the tarfile.version you are using to console and runs two tests, one for posix-mode up to path-length 256 and a second test for GNU-mode with pathlengths up to 1024. ### ###Testoutput with Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /home/frehberg/tmp/bin/python Tarfile Version: 0.8.0 TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=True) TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=False) ### ###Workarround for Python-2.5 ### (Assuming you are using Linux and Python-2.5 has been installed with prefix /usr/local/) Download tarfile-0.7.4 from http://www.gustaebel.de/lars/tarfile/ and run: ## remove original tarfile-module shipped with ## python2.5 rm -rf /usr/local/lib/python2.5/tarfile.py* ## install tarfile-0.7.4 tar -xvz -C /tmp/ -f /net/linux/pkg/python/tarfile-0.7.4.tar.gz cd /tmp/tarfile-0.7.4/ /usr/local/bin/python2.5 setup.py install ### ###Testoutput with patched Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /usr/local/bin/python Tarfile Version: 0.7.4 Tarfile module (posix=True) is Ok Tarfile module (posix=False) is Ok ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-06 22:22 Message: Logged In: YES user_id=849994 Originator: NO This was fixed by patch #1610437, thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&group_id=5470 From noreply at sourceforge.net Thu Dec 7 00:44:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 15:44:23 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 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=105470&aid=1610485&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Nobody/Anonymous (nobody) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Thu Dec 7 06:53:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Dec 2006 21:53:32 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) >Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Thu Dec 7 10:18:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 01:18:19 -0800 Subject: [ python-Bugs-1610654 ] cgi.py multipart/form-data Message-ID: Bugs item #1610654, was opened at 2006-12-07 09:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610654&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chui Tey (teyc) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py multipart/form-data Initial Comment: Uploading large binary files using multipart/form-data can be very inefficient because LF character may occur too frequently, resulting in the read_line_to_outer_boundary looping too many times. *** cgi.py.Py24 Thu Dec 7 18:46:13 2006 --- cgi.py Thu Dec 7 16:38:04 2006 *************** *** 707,713 **** last = next + "--" delim = "" while 1: ! line = self.fp.readline() if not line: self.done = -1 break --- 703,709 ---- last = next + "--" delim = "" while 1: ! line = self.fp_readline() if not line: self.done = -1 break *************** *** 729,734 **** --- 730,753 ---- delim = "" self.__write(odelim + line) + def fp_readline(self): + + tell = self.fp.tell() + buffer = self.fp.read(1 << 17) + parts = buffer.split("\n") + retlst = [] + for part in parts: + if part.startswith("--"): + if retlst: + retval = "\n".join(retlst) + "\n" + else: + retval = part + "\n" + self.fp.seek(tell + len(retval)) + return retval + else: + retlst.append(part) + return buffer + def skip_lines(self): """Internal: skip lines until outer boundary if defined.""" if not self.outerboundary or self.done: The patch reads the file in larger increments. For my test file of 138 Mb, it reduced parsing time from 168 seconds to 19 seconds. #------------ test script -------------------- import cgi import cgi import os import profile import stat def run(): filename = 'body.txt' size = os.stat(filename)[stat.ST_SIZE] fp = open(filename,'rb') environ = {} environ["CONTENT_TYPE"] = open('content_type.txt','rb').read() environ["REQUEST_METHOD"] = "POST" environ["CONTENT_LENGTH"] = str(size) fieldstorage = cgi.FieldStorage(fp, None, environ=environ) return fieldstorage import hotshot, hotshot.stats import time if 1: t1 = time.time() prof = hotshot.Profile("bug1718.prof") # hotshot profiler will crash with the # patch applied on windows xp #prof_results = prof.runcall(run) prof_results = run() prof.close() t2 = time.time() print t2-t1 if 0: for key in prof_results.keys(): if len(prof_results[key].value)> 100: print key, prof_results[key].value[:80] + "..." else: print key, prof_results[key] content_type.txt ---------------------------- multipart/form-data; boundary=----------ThIs_Is_tHe_bouNdaRY_$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610654&group_id=5470 From noreply at sourceforge.net Thu Dec 7 10:30:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 01:30:30 -0800 Subject: [ python-Feature Requests-1592899 ] "".translate() docs should mention string.maketrans() Message-ID: Feature Requests item #1592899, was opened at 2006-11-08 20:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ori Avtalion (salty-horse) Assigned to: Raymond Hettinger (rhettinger) Summary: "".translate() docs should mention string.maketrans() Initial Comment: The translate() documentation at http://docs.python.org/lib/string-methods.html#l2h-268 should mention the string.maketrans helper function. maketrans also mentions "regex.compile" - that should probably be "re.compile" (although it's less readable). re.compile should mention maketrans as well. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-07 09:30 Message: Logged In: YES user_id=849994 Originator: NO Cleared up both items in rev. 52951, 52952 (2.5). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 17:42 Message: Logged In: YES user_id=38376 Originator: NO Aha. The regex documentation says: compile (pattern[, translate]) /.../ The optional argument translate, if present, must be a 256-character string indicating how characters (both of the pattern and of the strings to be matched) are translated before comparing them; the i-th element of the string gives the translation for the character with ASCII code i. This can be used to implement case-insensitive matching; see the casefold data item below. which means that it was indeed useful for regex.compile. afaik, re.compile doesn't support arbitrary mappings, so that reference should be removed. ---------------------------------------------------------------------- Comment By: Ori Avtalion (salty-horse) Date: 2006-12-04 17:08 Message: Logged In: YES user_id=854801 Originator: YES >"re.compile should mention maketrans as well" >why? The maketrans doc says: "Return a translation table suitable for passing to translate() or regex.compile()" I don't have any use case for how it's useful to regex.compile. Maybe there is none, and the mention can be removed. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-12-04 09:20 Message: Logged In: YES user_id=38376 Originator: NO "re.compile should mention maketrans as well" why? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 From noreply at sourceforge.net Thu Dec 7 22:44:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 13:44:28 -0800 Subject: [ python-Bugs-1611131 ] \b in unicode regex gives strange results Message-ID: Bugs item #1611131, was opened at 2006-12-07 23:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&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: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: akaihola (akaihola) Assigned to: Gustavo Niemeyer (niemeyer) Summary: \b in unicode regex gives strange results Initial Comment: The problem: This doesn't give a match: >>> re.match(r'?\b', '? ', re.UNICODE) This works ok and gives a match: >>> re.match(r'.\b', '? ', re.UNICODE) Both of these work as well: >>> re.match(r'a\b', 'a ', re.UNICODE) >>> re.match(r'.\b', 'a ', re.UNICODE) Docs say \b is defined as an empty string between \w and \W. These do match accordingly: >>> re.match(r'\w', '?', re.UNICODE) >>> re.match(r'\w', 'a', re.UNICODE) >>> re.match(r'\W', ' ', re.UNICODE) So something strange happens in my first example, and I can't help but assume it's a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&group_id=5470 From noreply at sourceforge.net Thu Dec 7 23:18:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 14:18:43 -0800 Subject: [ python-Bugs-1611131 ] \b in unicode regex gives strange results Message-ID: Bugs item #1611131, was opened at 2006-12-07 23:44 Message generated for change (Comment added) made by akaihola You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&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: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: akaihola (akaihola) Assigned to: Gustavo Niemeyer (niemeyer) Summary: \b in unicode regex gives strange results Initial Comment: The problem: This doesn't give a match: >>> re.match(r'?\b', '? ', re.UNICODE) This works ok and gives a match: >>> re.match(r'.\b', '? ', re.UNICODE) Both of these work as well: >>> re.match(r'a\b', 'a ', re.UNICODE) >>> re.match(r'.\b', 'a ', re.UNICODE) Docs say \b is defined as an empty string between \w and \W. These do match accordingly: >>> re.match(r'\w', '?', re.UNICODE) >>> re.match(r'\w', 'a', re.UNICODE) >>> re.match(r'\W', ' ', re.UNICODE) So something strange happens in my first example, and I can't help but assume it's a bug. ---------------------------------------------------------------------- >Comment By: akaihola (akaihola) Date: 2006-12-08 00:18 Message: Logged In: YES user_id=1432932 Originator: YES As a work-around I currently use a regex like r'?(?=\W)'. Seems to work ok. Also, the \b problem doesn't seem to exist in the \W\w case, i.e. at the beginning of words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&group_id=5470 From noreply at sourceforge.net Thu Dec 7 23:25:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 14:25:27 -0800 Subject: [ python-Bugs-1611154 ] os.path.exists("file/") failure on Solaris 9 Message-ID: Bugs item #1611154, was opened at 2006-12-07 22:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611154&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists("file/") failure on Solaris 9 Initial Comment: Solaris 9 and earlier fail to conform to POSIX, in that stat("FILE/") succeeds even when FILE is not a directory. POSIX says that in this case it should fail. This problem causes os.path.exists("FILE/") to succeed when it should fail, which makes it harder to write portable Python code. One of my students ran into this problem when doing a Django-based project: his code ran fine on his Linux box, but failed when he attempted to run it on the Solaris 8 server that is the standard platform for our students. To reproduce the problem, on Solaris 8 (or 9): $ touch file $ ls -l file -rw-rw-r-- 1 eggert csfac 0 Dec 7 14:19 file $ python Python 2.5 (r25:51908, Dec 7 2006, 13:14:10) [GCC 4.1.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.exists("file/") True It should be False. I'll attach a patch that works around the problem at run-time. If you prefer something that tests for it at compile time please let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611154&group_id=5470 From noreply at sourceforge.net Fri Dec 8 01:14:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 16:14:49 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by g4rlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 >Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Fri Dec 8 06:13:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Dec 2006 21:13:00 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Fri Dec 8 18:18:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 09:18:45 -0800 Subject: [ python-Bugs-1611131 ] \b in unicode regex gives strange results Message-ID: Bugs item #1611131, was opened at 2006-12-07 22:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&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: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: akaihola (akaihola) Assigned to: Gustavo Niemeyer (niemeyer) Summary: \b in unicode regex gives strange results Initial Comment: The problem: This doesn't give a match: >>> re.match(r'?\b', '? ', re.UNICODE) This works ok and gives a match: >>> re.match(r'.\b', '? ', re.UNICODE) Both of these work as well: >>> re.match(r'a\b', 'a ', re.UNICODE) >>> re.match(r'.\b', 'a ', re.UNICODE) Docs say \b is defined as an empty string between \w and \W. These do match accordingly: >>> re.match(r'\w', '?', re.UNICODE) >>> re.match(r'\w', 'a', re.UNICODE) >>> re.match(r'\W', ' ', re.UNICODE) So something strange happens in my first example, and I can't help but assume it's a bug. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-08 18:18 Message: Logged In: YES user_id=21627 Originator: NO Notice that the re.UNICODE flag is only meaningful if you are using Unicode strings; in the examples you give, you are using byte strings. Please re-test with Unicode strings both as the expression and as the string to match. ---------------------------------------------------------------------- Comment By: akaihola (akaihola) Date: 2006-12-07 23:18 Message: Logged In: YES user_id=1432932 Originator: YES As a work-around I currently use a regex like r'?(?=\W)'. Seems to work ok. Also, the \b problem doesn't seem to exist in the \W\w case, i.e. at the beginning of words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&group_id=5470 From noreply at sourceforge.net Fri Dec 8 18:37:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 09:37:26 -0800 Subject: [ python-Bugs-1576657 ] dict keyerror formatting and tuples Message-ID: Bugs item #1576657, was opened at 2006-10-13 11:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&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: Python Interpreter Core Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: M.-A. Lemburg (lemburg) Assigned to: Georg Brandl (gbrandl) Summary: dict keyerror formatting and tuples Initial Comment: Probably just a minor glitch, but one which caused me half an hour to track down: >>> d = {1:'x'} >>> v = (1,) >>> d[v] Traceback (most recent call last): File "", line 1, in KeyError: 1 Note the formatting of the error message. It reads '1', not '(1,)' as you would expect. The example is constructed. In the code I was debugging, I didn't know that v was a tuple and thought it was the integer 1 - so the KeyError itself was somewhat puzzling. Only after printing the key I found that the lookup failed due to a type error. This happens in Python 2.4 and 2.5. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-08 12:37 Message: Logged In: YES user_id=80475 Originator: NO Added a similar fix to Objects/setobject.c in revision 52964. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-02 11:18 Message: Logged In: YES user_id=849994 Patch was committed as rev. 52535/6. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-14 02:16 Message: Logged In: YES user_id=849994 This is because a tuple as exception "argument" is automatically unpacked as the arguments on NormalizeException. Attaching patch that wraps all KeyErrors from dictionaries in a tuple. (There may be other objects and exceptions where this must be handled) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&group_id=5470 From noreply at sourceforge.net Fri Dec 8 19:45:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 10:45:47 -0800 Subject: [ python-Bugs-1611753 ] can't pickle NAN's in binary mode Message-ID: Bugs item #1611753, was opened at 2006-12-08 10:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611753&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wayne Christopher (wayne606) Assigned to: Nobody/Anonymous (nobody) Summary: can't pickle NAN's in binary mode Initial Comment: I think the problem is that pack(">d", float("nan")) does not work. Same for Inf. This works fine with pickle in ascii mode. I tried this on SuSE 10.0, x86_64. Python 2.4.2 (#2, Sep 10 2006, 23:53:27) [GCC 4.1.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> foo = [1, 2, float("nan")] >>> foo [1, 2, nan] >>> fp = file("/tmp/xxx", "wb") >>> pickle.dump(foo, fp, -1) Traceback (most recent call last): File "", line 1, in ? File "/home/software/64/lib/python2.4/pickle.py", line 1382, in dump Pickler(file, protocol, bin).dump(obj) File "/home/software/64/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/home/software/64/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/home/software/64/lib/python2.4/pickle.py", line 614, in save_list self._batch_appends(iter(obj)) File "/home/software/64/lib/python2.4/pickle.py", line 647, in _batch_appends save(x) File "/home/software/64/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/home/software/64/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611753&group_id=5470 From noreply at sourceforge.net Fri Dec 8 21:51:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 12:51:12 -0800 Subject: [ python-Bugs-1611131 ] \b in unicode regex gives strange results Message-ID: Bugs item #1611131, was opened at 2006-12-07 21:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&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: Regular Expressions Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: akaihola (akaihola) Assigned to: Gustavo Niemeyer (niemeyer) Summary: \b in unicode regex gives strange results Initial Comment: The problem: This doesn't give a match: >>> re.match(r'?\b', '? ', re.UNICODE) This works ok and gives a match: >>> re.match(r'.\b', '? ', re.UNICODE) Both of these work as well: >>> re.match(r'a\b', 'a ', re.UNICODE) >>> re.match(r'.\b', 'a ', re.UNICODE) Docs say \b is defined as an empty string between \w and \W. These do match accordingly: >>> re.match(r'\w', '?', re.UNICODE) >>> re.match(r'\w', 'a', re.UNICODE) >>> re.match(r'\W', ' ', re.UNICODE) So something strange happens in my first example, and I can't help but assume it's a bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-08 20:51 Message: Logged In: YES user_id=849994 Originator: NO FWIW, the first example works fine for me with and without Unicode strings. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-08 17:18 Message: Logged In: YES user_id=21627 Originator: NO Notice that the re.UNICODE flag is only meaningful if you are using Unicode strings; in the examples you give, you are using byte strings. Please re-test with Unicode strings both as the expression and as the string to match. ---------------------------------------------------------------------- Comment By: akaihola (akaihola) Date: 2006-12-07 22:18 Message: Logged In: YES user_id=1432932 Originator: YES As a work-around I currently use a regex like r'?(?=\W)'. Seems to work ok. Also, the \b problem doesn't seem to exist in the \W\w case, i.e. at the beginning of words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&group_id=5470 From noreply at sourceforge.net Fri Dec 8 22:51:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 13:51:27 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by g4rlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: g4rlik (g4rlik) Date: 2006-12-08 16:51 Message: Logged In: YES user_id=1662589 Originator: YES I'd just like to say thanks for looking into the problem. As for now, I can either deal with it or use Python 2.2, it's no problem. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Fri Dec 8 23:21:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 14:21:31 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 17:21 Message: Logged In: YES user_id=149084 Originator: NO OK, I'll close this for now. Feel free to reopen it if you come up with something definitive and/or can find others having the same problem. Can you give me a link to the discussion on help at python.org? ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-08 16:51 Message: Logged In: YES user_id=1662589 Originator: YES I'd just like to say thanks for looking into the problem. As for now, I can either deal with it or use Python 2.2, it's no problem. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Sat Dec 9 03:37:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 18:37:48 -0800 Subject: [ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file Message-ID: Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 From noreply at sourceforge.net Sat Dec 9 03:54:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 18:54:24 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by g4rlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: g4rlik (g4rlik) Date: 2006-12-08 21:54 Message: Logged In: YES user_id=1662589 Originator: YES I'm not exactly sure how I'd give you a link to the discussion on help at python.org. I was talking via e-mail and I'm not sure how to link that. Would you want me to copy and paste it? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 17:21 Message: Logged In: YES user_id=149084 Originator: NO OK, I'll close this for now. Feel free to reopen it if you come up with something definitive and/or can find others having the same problem. Can you give me a link to the discussion on help at python.org? ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-08 16:51 Message: Logged In: YES user_id=1662589 Originator: YES I'd just like to say thanks for looking into the problem. As for now, I can either deal with it or use Python 2.2, it's no problem. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Sat Dec 9 05:42:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 20:42:18 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 23:42 Message: Logged In: YES user_id=149084 Originator: NO Yes, please do. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-08 21:54 Message: Logged In: YES user_id=1662589 Originator: YES I'm not exactly sure how I'd give you a link to the discussion on help at python.org. I was talking via e-mail and I'm not sure how to link that. Would you want me to copy and paste it? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 17:21 Message: Logged In: YES user_id=149084 Originator: NO OK, I'll close this for now. Feel free to reopen it if you come up with something definitive and/or can find others having the same problem. Can you give me a link to the discussion on help at python.org? ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-08 16:51 Message: Logged In: YES user_id=1662589 Originator: YES I'd just like to say thanks for looking into the problem. As for now, I can either deal with it or use Python 2.2, it's no problem. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Sat Dec 9 06:45:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Dec 2006 21:45:57 -0800 Subject: [ python-Bugs-1612012 ] builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT Message-ID: Bugs item #1612012, was opened at 2006-12-09 16:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612012&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT Initial Comment: http://docs.python.org/lib/built-in-funcs.html doesn't mention the flag PyCF_DONT_IMPLY_DEDENT, as used by codeop.py in the stdlib. (I note that codeop.py has that flag as a literal, copied out of pythonrun.h - it should probably be exposed in some way). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612012&group_id=5470 From noreply at sourceforge.net Sat Dec 9 09:55:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 00:55:03 -0800 Subject: [ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file Message-ID: Bugs item #1611944, was opened at 2006-12-09 02:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&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: Python Library Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 08:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 From noreply at sourceforge.net Sat Dec 9 10:25:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 01:25:06 -0800 Subject: [ python-Bugs-1223238 ] race in os.makedirs() Message-ID: Bugs item #1223238, was opened at 2005-06-18 16:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&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: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:25 Message: Logged In: YES user_id=849994 Originator: NO Fixed by patch #1608267. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-05 01:32 Message: Logged In: YES user_id=832344 I agree that raising an error for existing directories is usually not what you want, but changing this will break any code that count on that documented behavior. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-07-18 12:08 Message: Logged In: YES user_id=432579 Whether the dir creation is done right-to-left or left-to-right is less important. If the expected usage pattern is that most of the directories already exist, then right-to-left may be faster, otherwise left-to-right is. One advantage with the former is its slightly simpler code (no need to check for ENOENT). >current 2.4 code does not return an error if the directory exists, >the patch must not change that behavior. You mean the contrary? From what I can see of the 2.4 code, it throws an error if the directory exists. This is almost never what you want, so I strongly doubt fixing that misfeature in 2.5 would break anything. I'm happy with the suggested patch for 2.5 in #1239890. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 21:10 Message: Logged In: YES user_id=832344 current 2.4 code does not return an error if the directory exists, the patch must not change that behavior. It will not be a good idea to change that behavior in 2.5 or any version, it can break lot of code. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-17 19:56 Message: Logged In: YES user_id=1188172 See patch #1239890. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-06-25 21:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 17:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 From noreply at sourceforge.net Sat Dec 9 10:56:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 01:56:00 -0800 Subject: [ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file Message-ID: Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Comment added) made by klankschap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&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: Python Library Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. ---------------------------------------------------------------------- >Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 From noreply at sourceforge.net Sat Dec 9 11:02:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 02:02:48 -0800 Subject: [ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file Message-ID: Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Comment added) made by klankschap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. ---------------------------------------------------------------------- >Comment By: Floris van Manen (klankschap) Date: 2006-12-09 11:02 Message: Logged In: YES user_id=1064918 Originator: YES Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start. ---------------------------------------------------------------------- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 From noreply at sourceforge.net Sat Dec 9 11:26:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 02:26:57 -0800 Subject: [ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file Message-ID: Bugs item #1611944, was opened at 2006-12-09 02:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 10:26 Message: Logged In: YES user_id=849994 Originator: NO I see. The problem is, as the "bext" chunk can be arbitrarily long, the test function would need more than 512 bytes to read the "fmt " chunk, or it could return that it cannot read the format details. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:02 Message: Logged In: YES user_id=1064918 Originator: YES Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start. ---------------------------------------------------------------------- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 09:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 08:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 From noreply at sourceforge.net Sat Dec 9 12:57:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 03:57:24 -0800 Subject: [ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers Message-ID: Bugs item #1612113, was opened at 2006-12-09 06:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 From noreply at sourceforge.net Sat Dec 9 13:01:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 04:01:06 -0800 Subject: [ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file Message-ID: Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Comment added) made by klankschap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. ---------------------------------------------------------------------- >Comment By: Floris van Manen (klankschap) Date: 2006-12-09 13:01 Message: Logged In: YES user_id=1064918 Originator: YES this could be a start. however the initial 512 bytes might be too short. i don't see (yet) how to increase that in a snazzy way. i just changed it into a read(1024) def test_wav_test( h ): if h[:4] != 'RIFF' or h[8:12] != 'WAVE': return None if h[12:16] == 'fmt ': style = get_short_le(h[20:22]) nchannels = get_short_le(h[22:24]) rate = get_long_le(h[24:28]) sample_bits = get_short_le(h[34:36]) return 'wav', rate, nchannels, -1, sample_bits elif h[12:16] == 'bext': offset = 12 while True: try: if h[offset:offset+4] == 'fmt ': nchannels = get_short_le( h[offset+10:offset+12] ) rate = get_long_le( h[offset+12:offset+16] ) sample_bits = get_short_le( h[offset+22:offset+24] ) return 'wav', rate, nchannels, -1, sample_bits offset += ( get_long_le( h[offset+4:offset+8] ) + 8 ) except IndexError: print 'header buffer too short' return None ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 11:26 Message: Logged In: YES user_id=849994 Originator: NO I see. The problem is, as the "bext" chunk can be arbitrarily long, the test function would need more than 512 bytes to read the "fmt " chunk, or it could return that it cannot read the format details. Would you like to work on a patch? ---------------------------------------------------------------------- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 11:02 Message: Logged In: YES user_id=1064918 Originator: YES Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start. ---------------------------------------------------------------------- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 From noreply at sourceforge.net Sat Dec 9 15:31:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 06:31:26 -0800 Subject: [ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers Message-ID: Bugs item #1612113, was opened at 2006-12-09 12:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-09 15:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 From noreply at sourceforge.net Sat Dec 9 15:37:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 06:37:33 -0800 Subject: [ python-Bugs-1611753 ] can't pickle NAN's in binary mode Message-ID: Bugs item #1611753, was opened at 2006-12-08 18:45 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611753&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: Python Library Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Wayne Christopher (wayne606) >Assigned to: Michael Hudson (mwh) Summary: can't pickle NAN's in binary mode Initial Comment: I think the problem is that pack(">d", float("nan")) does not work. Same for Inf. This works fine with pickle in ascii mode. I tried this on SuSE 10.0, x86_64. Python 2.4.2 (#2, Sep 10 2006, 23:53:27) [GCC 4.1.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> foo = [1, 2, float("nan")] >>> foo [1, 2, nan] >>> fp = file("/tmp/xxx", "wb") >>> pickle.dump(foo, fp, -1) Traceback (most recent call last): File "", line 1, in ? File "/home/software/64/lib/python2.4/pickle.py", line 1382, in dump Pickler(file, protocol, bin).dump(obj) File "/home/software/64/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/home/software/64/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/home/software/64/lib/python2.4/pickle.py", line 614, in save_list self._batch_appends(iter(obj)) File "/home/software/64/lib/python2.4/pickle.py", line 647, in _batch_appends save(x) File "/home/software/64/lib/python2.4/pickle.py", line 293, in save f(self, obj) # Call unbound method with explicit self File "/home/software/64/lib/python2.4/pickle.py", line 489, in save_float self.write(BINFLOAT + pack('>d', obj)) SystemError: frexp() result out of range ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-12-09 14:37 Message: Logged In: YES user_id=6656 Originator: NO This is fixed in 2.5 (and if you think it worked fine in ASCII mode, I don't think you tried moving your pickles between Linux and Windows systems...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611753&group_id=5470 From noreply at sourceforge.net Sat Dec 9 15:51:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 06:51:48 -0800 Subject: [ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers Message-ID: Bugs item #1612113, was opened at 2006-12-09 06:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None Status: Pending Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-12-09 09:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-09 09:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 From noreply at sourceforge.net Sat Dec 9 16:19:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 07:19:17 -0800 Subject: [ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish Message-ID: Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by g4rlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: Python 2.5 Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from help at python.org was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. ---------------------------------------------------------------------- >Comment By: g4rlik (g4rlik) Date: 2006-12-09 10:19 Message: Logged In: YES user_id=1662589 Originator: YES Here are some important bits from the first e-mails. "Dear Will, > Hello there. I'll keep this short and sweet for you, seeing as > you're a volunteer (thank you by the way!). Hello! We're glad to help. > The Python GUI for versions 2.3, 2.4, and 2.5 are very slow on my > computer. Whenever I type in the GUI or simply move the GUI around > my desktop, its response time is slower than normal. However, the > GUIs of Python versions 2.2 and below are not slow at all for me. I'm not at all sure, but the timing suggests that the problem may be in IDLE's using a subprocess. If that's the explanation, you should see something different if you start IDLE without a subprocess. You ought to be able to do that by opening a command-shell window and typing something like: c:\python25\python c:\python25\Lib\idlelib\idle.py -n Of course, your directory names may be different. If that does improve IDLE's performance, that still leaves the question of why a subprocess performs much worse on your computer than on most people's. Let us know what you get. Someone else here may have a different idea or a better idea about that one. Regards, Matt" "I'm a trifle curious why a loopback network connection and a subprocess should load your machine so much, but I doubt that it would be easy to figure that out by email." ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 23:42 Message: Logged In: YES user_id=149084 Originator: NO Yes, please do. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-08 21:54 Message: Logged In: YES user_id=1662589 Originator: YES I'm not exactly sure how I'd give you a link to the discussion on help at python.org. I was talking via e-mail and I'm not sure how to link that. Would you want me to copy and paste it? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 17:21 Message: Logged In: YES user_id=149084 Originator: NO OK, I'll close this for now. Feel free to reopen it if you come up with something definitive and/or can find others having the same problem. Can you give me a link to the discussion on help at python.org? ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-08 16:51 Message: Logged In: YES user_id=1662589 Originator: YES I'd just like to say thanks for looking into the problem. As for now, I can either deal with it or use Python 2.2, it's no problem. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. ---------------------------------------------------------------------- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=1662589 Originator: YES I ran some programs to get rid of adaware and spyware and then tried to run the GUI for 2.5. I still have the problem. After that I unplugged my router (which has the internal firewall) and attempted to test the GUI's speed again. It was still sluggish. When running the GUI and looking in Task Manager, it uses <1% of my CPU's power. By the way, the specs for my computer are: AMD Athlon XP 2800+ (2.08ghz) 1 gig RAM I don't have an amazing rig, but that should do more than fine for running Python. I don't believe my CPU and RAM are my problems. Oh well, I don't think there is much more looking into this that I can do. I'll either have to live with the sluggishness or run Python 2.2. Thanks. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 From noreply at sourceforge.net Sat Dec 9 16:48:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 07:48:39 -0800 Subject: [ python-Feature Requests-1612190 ] Py_DEBUG Message-ID: Feature Requests item #1612190, was opened at 2006-12-09 16:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&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: nitro (nitrogenycs) Assigned to: Nobody/Anonymous (nobody) Summary: Py_DEBUG Initial Comment: Hello, I am writing an extension module (Win32, VC8). Of course I need to #include . Now, when _DEBUG is defined in my application Py_DEBUG gets defined as well (in pyconfig.h). I don't want this to happen as I have to link to the python debug library that way. However, I don't want to debug python, I only want to debug my own application. So the automatic definition of Py_DEBUG doesn't seem right. A solution that would be backwards compatible could look like: #ifdef _DEBUG && !defined(Py_NO_DEBUG) # define Py_DEBUG #endif Could something like this be included in python? Note that #undef _DEBUG #include #define _DEBUG does not work as VC8 complains in this case, because some header files had the _DEBUG preprocessor symbol and some didn't. That trick used to work in VC 6 and 7.x. I've seen a lot of people fighting this problem. Another problem that also arises from pyconfig.h is this code: # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else I don't think it's clean that python tells my program what to link to. I am the one who should (and wants to) do this via a linker switch. I know that some people probably would regard the code above as a feature, but it's the opposite imo. A backwards compatible change could look like: #ifdef MS_COREDLL # ifndef Py_BUILD_CORE /* not building the core - must be an ext */ # if defined(_MSC_VER) && !defined(Py_NO_AUTOMATIC_MSVC_LINK) /* So MSVC users need not specify the .lib file in their Makefile (other compilers are generally taken care of by distutils.) */ # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else # pragma comment(lib,"python24.lib") # endif /* _DEBUG */ # endif /* _MSC_VER */ # endif /* Py_BUILD_CORE */ #endif /* MS_COREDLL */ Thanks, -Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 From noreply at sourceforge.net Sat Dec 9 17:55:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 08:55:56 -0800 Subject: [ python-Feature Requests-1528593 ] Printing: No print dialog or page setup Message-ID: Feature Requests item #1528593, was opened at 2006-07-25 22:49 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&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: Python 2.6 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Printing: No print dialog or page setup Initial Comment: The printing solution for IDLE on OSX is lacking a page setup dialog, or even a print dialog. This means output will also be sent to the default printer. If there is no default printer (which means the user hasn't defined a printer at all) the user will get a confusing message (lpr failed). BTW. the message is clear for technical users, but not for mac users that aren't unix saffy. It would be nice if IDLE could interface with the Carbon/Cocoa print system using a real print dialog. That way users can select another than the default printer, change page settings and can even print to PDF. I've filed this as a low-priority issue for 2.6 because there's no way this will get into 2.5 and it likey non-trivial as well. BTW. this might be a feature-request rather than a bug. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-12-09 18:55 Message: Logged In: YES user_id=1330769 Originator: NO This is a problem on all platforms. We have recently been discussing possible solutions for Windows platforms, but until now haven't found a solution that doesn't require the 'win32' package. The Unix/Linux platforms could probably be addressed without special modules/packages... ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:45 Message: Logged In: YES user_id=149084 It's not just an OSX problem. Printing in IDLE is very rudimentary at this point. Making this an RFE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&group_id=5470 From noreply at sourceforge.net Sat Dec 9 17:58:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 08:58:11 -0800 Subject: [ python-Feature Requests-404444 ] [IDLE] auto indent/parentheses Message-ID: Feature Requests item #404444, was opened at 2001-02-27 01:46 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=404444&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: Later Priority: 5 Private: No Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: [IDLE] auto indent/parentheses Initial Comment: It'd be really nice to have an automatic indent of a line when using the "TAB" key anywhere on the line, this feature exist in the python emacs mode and is REALLY nice and a total time-saver. Also, having the possibility to see which parentheses/brackets you're closing while typing (as in a lot of editors) would be really nice ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-12-09 18:58 Message: Logged In: YES user_id=1330769 Originator: NO The Parentheses/Bracket feature is already addressed by the ParenMatch extension. I agree that an "auto-indent-line" function would be very time-saving. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:47 Message: Logged In: YES user_id=31435 Chagned Category to IDLE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-18 21:32 Message: Logged In: YES user_id=31435 Hmm. SF threw us another curve ball here: the new "Data Type" value "Feature Requests" has only "None" as a possible value for "Assigned To". The intro text in PEP 42 doesn't know about this either ... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-03-18 18:32 Message: Logged In: YES user_id=12800 Thomas explained it nicely in a followup to the PEP 42 checkin. Included here for completeness. "The TAB comment is pretty easy to explain: the user wants IDLE to re-indent the *current* line whenever he presses TAB, regardless of where his cursor is at that moment." Indeed, this is how python-mode (and most language editing modes) in Emacs works. You typically have to type ^Q TAB to get a real tab character inserted. Assigning to Guido since he's the most enthusiastic IDLE hacker, but moving it to Feature Requests and re-opening. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-17 21:55 Message: Logged In: YES user_id=31435 Added to PEP 42 and marked Later/Closed. Assigned to Barry in the hopes that he can clarify the TAB business (I don't understand what this is asking for -- doesn't a TAB key act like a TAB key <wink> in Emacs? maybe I always rebound it in my Emacs days). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=404444&group_id=5470 From noreply at sourceforge.net Sat Dec 9 18:33:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 09:33:39 -0800 Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE Message-ID: Bugs item #1571112, was opened at 2006-10-05 06:46 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&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: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Douglas W. Goodall (douglas_goodall) Assigned to: Kurt B. Kaiser (kbk) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-12-09 19:33 Message: Logged In: YES user_id=1330769 Originator: NO This cause for this bug is an endless loop in AutoCompleteWindow.py, line 121: 114 selstart = self.completions[cursel] [snip...] 121 while cursel > 0 and selstart[:i] <= self.completions[cursel-1]: 122 i += 1 123 newstart = selstart[:i] The case where this loop becomes endless only arises when the same completion item appears twice in the completions list, thus self.completions[cursel-1] and self.completions[cursel] are identical. This happens with the os module because spawnv and spawnve appear twice in os.__all__. Solution: 1) Fix the potentially endless loop (add a bound for i) 2) Remove identical completion items from the completions list (its a bug anyways) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-08 19:47 Message: Logged In: YES user_id=580910 As an additional data point: this seems to work just fine on Mac OS X. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-08 05:16 Message: Logged In: YES user_id=80475 I can reproduce this in Py2.5 final. This may be a TkInter bug and not unique to IDLE or to Windows. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 18:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 From noreply at sourceforge.net Sat Dec 9 18:38:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 09:38:55 -0800 Subject: [ python-Feature Requests-1612262 ] Class Browser doesn't show internal classes Message-ID: Feature Requests item #1612262, was opened at 2006-12-09 19:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612262&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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Class Browser doesn't show internal classes Initial Comment: If I define a class within a class, like this: class A: class B: pass def foo(self): pass The class browser shows that A contains foo, but it doesn't show B at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612262&group_id=5470 From noreply at sourceforge.net Sat Dec 9 18:45:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 09:45:00 -0800 Subject: [ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work Message-ID: Bugs item #1566611, was opened at 2006-09-27 23:24 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&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: 5 Private: No Submitted By: fladd (fladd710) Assigned to: Kurt B. Kaiser (kbk) Summary: Idle 1.2 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-12-09 19:45 Message: Logged In: YES user_id=1330769 Originator: NO You mean 2.5 final is suppose... Works for me, Python 2.5 final, WinXP Pro. Does this never work or only sometimes? Have you checked you key definitions? Does it work in the Shell window? Please be more specific... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 From noreply at sourceforge.net Sat Dec 9 18:54:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Dec 2006 09:54:29 -0800 Subject: [ python-Bugs-1562193 ] IDLE Hung up after open script by command line... Message-ID: Bugs item #1562193, was opened at 2006-09-20 16:10 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marek Nowicki (faramir2) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE Hung up after open script by command line... Initial Comment: Hello, I wrote that code in python and saved as prx.py: --- CUT --- from BaseHTTPServer import HTTPServer, BaseHTTPRequestHandler from time import strftime, gmtime import urllib2 import thread from sys import stdout class RequestHandler(BaseHTTPRequestHandler): def serve(self): print "%s %s %s\r\n%s" % (self.command, self.path, self.request_version, self.headers) header={} header["content-length"]=0 for i in str(self.headers).split("\r\n"): j=i.split(":", 1) if len(j)==2: header[j[0].strip().lower()] = j[1].strip() content=self.rfile.read(int(header["content- length"])) print content url="http://faramir2.prv.pl" u=urllib2.urlopen(url) for i,j in u.info().items(): print "%s: %s" % (i,j) self.server_version = "Apache" self.sys_version = "" self.send_response(200) self.send_header("Content-type", "text/html; charset=ISO-8859-2") self.send_header("Connectin", "close") self.end_headers() def do_POST(self): self.serve() def do_HEAD(self): self.serve() def do_GET(self): self.serve() address = ("", 80) server = HTTPServer(address, RequestHandler) thread.start_new_thread(server.serve_forever, () ) --- CUT --- When I right click on that file and select "Edit with IDLE" it opens. Then when I push F5 the script is running. *Python Shell* is restarting. But when I try to connect by browser to http:// localhost:80/ IDLE Hung-up. I don't see that hung ups when I open IDLE from shortcut and then in IDLE open file prx.py and run it works normally - good. IDLE does't hung up. I don't know why it works like that, but I think that it's bug.. Python version: 2.5c2 Tk version: 8.4 IDLE version: 1.2c2 OS Version: Microsoft Windows XP Professional with SP2 --- Again: * Freeze: > "C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw" -n -e "prx.py" // then F5 on IDLE // when run open Browser and try to open page: http:// localhost:80 // IDLE freezes * Works ok: > "C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw" -e // open prx.py in IDLE // press F5 on IDLE // run Browwser and try to open page: http:// localhost:80 // all works ok --- regards, Marek ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-12-09 19:54 Message: Logged In: YES user_id=1330769 Originator: NO Well, the issue obviously only happens when IDLE is running without a subprocess. The code you pasted is unindtented so I'm not going to try it out... My guess would be that your server is blocking in a way that it blocks all threads. This is why, when it is run in the same process as IDLE's GUI, IDLE hangs. However, when you run IDLE with a subprocess, it's the subprocess which is blocked, so IDLE works normally. (this is what the subprocess is there for :) In any case, IDLE is behaving just fine here. This isn't a bug in IDLE. This could be a bug with the thread module, or a bug in BaseHTTPServer, or several other places. But it is most likely caused by some misunderstanding on your part of blocking operations, threads, and the interaction between them. You should have tried posting this on c.l.py before posting a bug on SF, and I suggest you do so now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470 From noreply at sourceforge.net Sun Dec 10 20:35:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Dec 2006 11:35:39 -0800 Subject: [ python-Bugs-1612729 ] webchecker/urllib chokes on 404 pages Message-ID: Bugs item #1612729, was opened at 2006-12-10 20:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612729&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: Open Resolution: None Priority: 7 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker/urllib chokes on 404 pages Initial Comment: platform: standard Python 2.5 on Windows XP. webchecker chokes on reponse code 404, which is a bit unfortunate... the error occurs deep down in urllib, but a plain urllib request to the same page don't result in the same errors, so it's probably related to how webchecker is using the library. here's an example: C:\Python25\Tools\webchecker> python webchecker.py http://www.python.org/foo webchecker version 50851 Round 1 (1 total, 1 to do, 0 done, 0 bad) No need to save checkpoint Traceback (most recent call last): File "webchecker.py", line 892, in main() File "webchecker.py", line 222, in main c.run() File "webchecker.py", line 349, in run self.dopage(url) File "webchecker.py", line 404, in dopage page = self.getpage(url_pair) File "webchecker.py", line 509, in getpage text, nurl = self.readhtml(url_pair) File "webchecker.py", line 523, in readhtml f, url = self.openhtml(url_pair) File "webchecker.py", line 531, in openhtml f = self.openpage(url_pair) File "webchecker.py", line 543, in openpage return self.urlopener.open(url) File "c:\python25\lib\urllib.py", line 190, in open return getattr(self, name)(url) File "c:\python25\lib\urllib.py", line 334, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "c:\python25\lib\urllib.py", line 351, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "c:\python25\lib\urllib.py", line 357, in http_error_default raise IOError, ('http error', errcode, errmsg, headers) TypeError: EnvironmentError expected at most 3 arguments, got 4 running the same test under Python 2.4 works fine: C:\python24\Tools\webchecker>python webchecker.py http://www.python.org/foo webchecker version 36560 Round 1 (1 total, 1 to do, 0 done, 0 bad) Error ('http error', 404, 'Not Found') HREF http://www.python.org/foo from Final Report (1 total, 0 to do, 1 done, 1 bad) Error Report: Error in HREF http://www.python.org/foo msg ('http error', 404, 'Not Found') Saving checkpoint to @webchecker.pickle ... Done. Use ``webchecker.py -R'' to restart. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612729&group_id=5470 From noreply at sourceforge.net Mon Dec 11 11:25:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 02:25:30 -0800 Subject: [ python-Bugs-1612729 ] webchecker/urllib chokes on 404 pages Message-ID: Bugs item #1612729, was opened at 2006-12-10 19:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612729&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: Duplicate Priority: 7 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker/urllib chokes on 404 pages Initial Comment: platform: standard Python 2.5 on Windows XP. webchecker chokes on reponse code 404, which is a bit unfortunate... the error occurs deep down in urllib, but a plain urllib request to the same page don't result in the same errors, so it's probably related to how webchecker is using the library. here's an example: C:\Python25\Tools\webchecker> python webchecker.py http://www.python.org/foo webchecker version 50851 Round 1 (1 total, 1 to do, 0 done, 0 bad) No need to save checkpoint Traceback (most recent call last): File "webchecker.py", line 892, in main() File "webchecker.py", line 222, in main c.run() File "webchecker.py", line 349, in run self.dopage(url) File "webchecker.py", line 404, in dopage page = self.getpage(url_pair) File "webchecker.py", line 509, in getpage text, nurl = self.readhtml(url_pair) File "webchecker.py", line 523, in readhtml f, url = self.openhtml(url_pair) File "webchecker.py", line 531, in openhtml f = self.openpage(url_pair) File "webchecker.py", line 543, in openpage return self.urlopener.open(url) File "c:\python25\lib\urllib.py", line 190, in open return getattr(self, name)(url) File "c:\python25\lib\urllib.py", line 334, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "c:\python25\lib\urllib.py", line 351, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "c:\python25\lib\urllib.py", line 357, in http_error_default raise IOError, ('http error', errcode, errmsg, headers) TypeError: EnvironmentError expected at most 3 arguments, got 4 running the same test under Python 2.4 works fine: C:\python24\Tools\webchecker>python webchecker.py http://www.python.org/foo webchecker version 36560 Round 1 (1 total, 1 to do, 0 done, 0 bad) Error ('http error', 404, 'Not Found') HREF http://www.python.org/foo from Final Report (1 total, 0 to do, 1 done, 1 bad) Error Report: Error in HREF http://www.python.org/foo msg ('http error', 404, 'Not Found') Saving checkpoint to @webchecker.pickle ... Done. Use ``webchecker.py -R'' to restart. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-11 10:25 Message: Logged In: YES user_id=849994 Originator: NO This is a known issue (another exception object rewrite relic) and has been fixed as response to bug #1566800. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612729&group_id=5470 From noreply at sourceforge.net Mon Dec 11 11:52:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 02:52:11 -0800 Subject: [ python-Bugs-1613059 ] lambda tuple parameter bus error Message-ID: Bugs item #1613059, was opened at 2006-12-11 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=105470&aid=1613059&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: 5 Private: No Submitted By: Bruce Cropley (cropley_b) Assigned to: Nobody/Anonymous (nobody) Summary: lambda tuple parameter bus error Initial Comment: Python 2.5c1 (r25c1:51305, Aug 17 2006, 10:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> lambda ((a,b)): 1 [... popped up windows crash reporting dialog] Same with: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin >>> lambda ((a,b)): 1 Bus error However it works with 2.4.1 and 2.3.5 on OSX and on 2.3.3 and 2.4 on Windows, e.g.: PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond at skippinet.com.au) - see 'Help/About PythonWin' for further copyright information. >>> lambda ((a,b)): 1 at 0x00AC48B0> >>> f = lambda ((a,b)): 1 >>> assert f((1,2)) == 1 >>> The workaround is to remove the unnecessary parentheses around the lambda's tuple of parameters: >>> f = lambda (a,b): 1 Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613059&group_id=5470 From noreply at sourceforge.net Mon Dec 11 12:34:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 03:34:54 -0800 Subject: [ python-Bugs-1613059 ] lambda tuple parameter bus error Message-ID: Bugs item #1613059, was opened at 2006-12-11 10:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613059&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: Out of Date Priority: 5 Private: No Submitted By: Bruce Cropley (cropley_b) Assigned to: Nobody/Anonymous (nobody) Summary: lambda tuple parameter bus error Initial Comment: Python 2.5c1 (r25c1:51305, Aug 17 2006, 10:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> lambda ((a,b)): 1 [... popped up windows crash reporting dialog] Same with: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin >>> lambda ((a,b)): 1 Bus error However it works with 2.4.1 and 2.3.5 on OSX and on 2.3.3 and 2.4 on Windows, e.g.: PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond at skippinet.com.au) - see 'Help/About PythonWin' for further copyright information. >>> lambda ((a,b)): 1 at 0x00AC48B0> >>> f = lambda ((a,b)): 1 >>> assert f((1,2)) == 1 >>> The workaround is to remove the unnecessary parentheses around the lambda's tuple of parameters: >>> f = lambda (a,b): 1 Thanks! ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-11 11:34 Message: Logged In: YES user_id=849994 Originator: NO This has already been fixed in SVN, the fix will be part of 2.5.1. Thanks for reporting anyway! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613059&group_id=5470 From noreply at sourceforge.net Mon Dec 11 14:03:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 05:03:23 -0800 Subject: [ python-Bugs-1613130 ] str.split creates new string even if pattern not found Message-ID: Bugs item #1613130, was opened at 2006-12-11 14:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: str.split creates new string even if pattern not found Initial Comment: Hello, Several string methods avoid allocating a new string when the operation result is trivially the same as one of the parameters (e.g. replacing a non-existing substring). However, split() does not exhibit this optimization, it always constructs a new string even if no splitting occurs: $ python Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> s = "abcde" * 2 >>> id(s) 3084139400L >>> id(str(s)) 3084139400L >>> id("" + s) 3084139400L >>> id(s.strip()) 3084139400L >>> id(s.replace("g", "h")) 3084139400L >>> [id(x) for x in s.partition("h")] [3084139400L, 3084271768L, 3084271768L] >>> [id(x) for x in s.split("h")] [3084139360L] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470 From noreply at sourceforge.net Mon Dec 11 15:42:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 06:42:48 -0800 Subject: [ python-Bugs-1503765 ] logger.config problems with comma separated lists Message-ID: Bugs item #1503765, was opened at 2006-06-09 23:04 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&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: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: cuppatea (cuppatea) Assigned to: Vinay Sajip (vsajip) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-11 14:42 Message: Logged In: YES user_id=308438 Originator: NO Applied a modified version of this patch to SVN - trunk and release24-maint. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:20 Message: Logged In: YES user_id=849994 Attaching a real patch and assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 From noreply at sourceforge.net Mon Dec 11 16:05:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 07:05:16 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 09:29 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&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: Python Library Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Pieter Zieschang (mad-marty) Assigned to: Vinay Sajip (vsajip) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-11 15:05 Message: Logged In: YES user_id=308438 Originator: NO I'm not sure this should be treated as a logging bug - after all, psyco is not part of standard Python and logging is only tested as a part of standard Python. Possibly this should be logged under psyco rather than Python logging. Meanwhile, if time permits I will take a look at this. ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-12-02 01:09 Message: Logged In: YES user_id=1269426 Originator: YES Hi, after some investigation, I think I found the source. Just add 'import psyco; psyco.full()' to test.py aufer imports and you get the same problem with your example. It seems, logging is not compatible with the way psyco creates proxy functions. Could be that sys._getframe returns something different. - just a guess But it works with the old logging. Is there any other information you may want ? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-11-30 09:18 Message: Logged In: YES user_id=308438 Originator: NO I need more information. For example (N.B. lines may wrap, please adjust if copy/pasting the code below): #-- test.py import module import logging logging.basicConfig(level=logging.DEBUG, format="%(relativeCreated)-6d %(module)s %(filename)s %(lineno)d - %(message)s") logging.getLogger("test").debug("Test starting, about to start thread...") threads = module.start() for t in threads: t.join() logging.getLogger("test").debug("All done.") #-- test.py ends #-- module.py import logging import threading import random import time class MyThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break class MyOtherThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break def start(): t1 = MyThread(name="Thread One") t2 = MyOtherThread(name="Thread Two") t1.start() t2.start() return t1, t2 #-- module.py ends When I run test, I get the following output: 15 test test.py 7 - Test starting, about to start thread... 15 module module.py 11 - Running in thread: Thread One 15 module module.py 22 - Running in thread: Thread Two 327 module module.py 11 - Running in thread: Thread One 343 module module.py 22 - Running in thread: Thread Two 655 module module.py 11 - Running in thread: Thread One 780 module module.py 22 - Running in thread: Thread Two 1000 module module.py 11 - Running in thread: Thread One 1546 module module.py 22 - Running in thread: Thread Two 1890 module module.py 11 - Running in thread: Thread One 2046 module module.py 11 - Running in thread: Thread One 2218 module module.py 22 - Running in thread: Thread Two 2562 module module.py 22 - Running in thread: Thread Two 3187 test test.py 11 - All done. This is the expected output. Python version used: ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 12:02 Message: Logged In: YES user_id=1269426 Originator: YES Checked again and found that the bug was introduced with Python 2.4.2. Last correctly working version is python-2.4.1.msi. ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 09:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Mon Dec 11 20:09:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 11:09:08 -0800 Subject: [ python-Feature Requests-1612190 ] Py_DEBUG Message-ID: Feature Requests item #1612190, was opened at 2006-12-09 16:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&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: nitro (nitrogenycs) Assigned to: Nobody/Anonymous (nobody) Summary: Py_DEBUG Initial Comment: Hello, I am writing an extension module (Win32, VC8). Of course I need to #include . Now, when _DEBUG is defined in my application Py_DEBUG gets defined as well (in pyconfig.h). I don't want this to happen as I have to link to the python debug library that way. However, I don't want to debug python, I only want to debug my own application. So the automatic definition of Py_DEBUG doesn't seem right. A solution that would be backwards compatible could look like: #ifdef _DEBUG && !defined(Py_NO_DEBUG) # define Py_DEBUG #endif Could something like this be included in python? Note that #undef _DEBUG #include #define _DEBUG does not work as VC8 complains in this case, because some header files had the _DEBUG preprocessor symbol and some didn't. That trick used to work in VC 6 and 7.x. I've seen a lot of people fighting this problem. Another problem that also arises from pyconfig.h is this code: # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else I don't think it's clean that python tells my program what to link to. I am the one who should (and wants to) do this via a linker switch. I know that some people probably would regard the code above as a feature, but it's the opposite imo. A backwards compatible change could look like: #ifdef MS_COREDLL # ifndef Py_BUILD_CORE /* not building the core - must be an ext */ # if defined(_MSC_VER) && !defined(Py_NO_AUTOMATIC_MSVC_LINK) /* So MSVC users need not specify the .lib file in their Makefile (other compilers are generally taken care of by distutils.) */ # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else # pragma comment(lib,"python24.lib") # endif /* _DEBUG */ # endif /* _MSC_VER */ # endif /* Py_BUILD_CORE */ #endif /* MS_COREDLL */ Thanks, -Matthias ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-11 20:09 Message: Logged In: YES user_id=21627 Originator: NO You should just not define _DEBUG then. You don't need to define _DEBUG to perform debugging; instead, _DEBUG requests that the debug version of the MS CRT is linked to your application. As mixing different CRTs (e.g. debug and non-debug) in a single application can cause crashes, you *must* use a python2x.dll that is linked with the debug CRT; this will be python2x_d.dll. So no, something like this should not be added to Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 From noreply at sourceforge.net Mon Dec 11 21:40:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 12:40:12 -0800 Subject: [ python-Bugs-1613479 ] pydoc info for a package doesn't list all package contents Message-ID: Bugs item #1613479, was opened at 2006-12-11 12:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613479&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nishkar Grover (ngrover) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc info for a package doesn't list all package contents Initial Comment: When using pydoc to query a package, a "PACKAGE CONTENTS" list is provided to show the modules and packages that are in that package. That list will be incomplete if we are querying a package that has been split across multiple directories. Suppose you have the following: /first/path/foo/__init__.py /first/path/foo/one.py /second/path/foo/__init__.py /second/path/foo/two.py and sys.path includes /first/path/ and /second/path/. If both of the foo/__init__.py files are empty, then "import foo" will only allow you to import modules from one of those two foo/ directories (whichever is found first in sys.path). However, if we add the following to both foo/__init__.py files, then we can import foo.one and foo.two because "foo" is considered to be a single package split across two directories: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) Please see http://www.python.org/doc/2.4.2/lib/module-pkgutil.html for some related information. On line 1052 of pydoc.py, we have the following: for file in os.listdir(object.__path__[0]): and in that loop we only read the contents of the FIRST directory in the package's __path__. That should be updated to read the contents of ALL directories in the package's __path__. The following change will do that: % diff -w pydoc.py pydoc.py.orig 1052,1054c1052,1053 < for objectDir in object.__path__: < for file in os.listdir(objectDir): < path = os.path.join(objectDir, file) --- > for file in os.listdir(object.__path__[0]): > path = os.path.join(object.__path__[0], file) I've attached that updated pydoc.py file to this submission. Please consider that as a replacement for the existing pydoc.py module that's currently being distributed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613479&group_id=5470 From noreply at sourceforge.net Tue Dec 12 00:17:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 15:17:38 -0800 Subject: [ python-Bugs-1613573 ] xmlrpclib ServerProxy uses old httplib interface Message-ID: Bugs item #1613573, was opened at 2006-12-12 12:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Brown (mattgbrown) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib ServerProxy uses old httplib interface Initial Comment: The ServerProxy class of the xmlrpclib module uses the old style HTTP / HTTPS classes of the httplib module rather than the newer HTTPConnection and HTTPConnection classes. The practical result of this is that xmlrpc connections are not able to make use of HTTP/1.1 functionality. Please update the xmlrpclib module to use the newer API provided by httplib so that the advanced functionality of HTTP/1.1 is available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&group_id=5470 From noreply at sourceforge.net Tue Dec 12 03:29:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Dec 2006 18:29:49 -0800 Subject: [ python-Bugs-1613651 ] recv_into not documented Message-ID: Bugs item #1613651, was opened at 2006-12-11 18:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613651&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: 5 Private: No Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: recv_into not documented Initial Comment: The recv_into socket method does not appear to be documented in the Library Reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613651&group_id=5470 From noreply at sourceforge.net Tue Dec 12 12:35:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 03:35:10 -0800 Subject: [ python-Bugs-1613130 ] str.split creates new string even if pattern not found Message-ID: Bugs item #1613130, was opened at 2006-12-11 14:03 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: str.split creates new string even if pattern not found Initial Comment: Hello, Several string methods avoid allocating a new string when the operation result is trivially the same as one of the parameters (e.g. replacing a non-existing substring). However, split() does not exhibit this optimization, it always constructs a new string even if no splitting occurs: $ python Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> s = "abcde" * 2 >>> id(s) 3084139400L >>> id(str(s)) 3084139400L >>> id("" + s) 3084139400L >>> id(s.strip()) 3084139400L >>> id(s.replace("g", "h")) 3084139400L >>> [id(x) for x in s.partition("h")] [3084139400L, 3084271768L, 3084271768L] >>> [id(x) for x in s.split("h")] [3084139360L] ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2006-12-12 12:35 Message: Logged In: YES user_id=133955 Originator: YES Ok, I did a patch which partially adds the optimization (the patch is at home, I can't post it right now). I have a few questions though: - there is a USE_FAST flag which can bring some speedups when a multicharacter separator is used; however, it is not enabled by default, is there a reason for this? - where and by whom is maintained stringbench.py, so that I can propose additional tests for it (namely, tests for unmatched split())? - split() implementation is duplicated between str and unicode (the unicode versions having less optimizations), would it be useful to "stringlib'ify" split()? - rsplit() does quite similar things as split(), has anyone tried to factor similar parts? do you see any caveats doing so? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470 From noreply at sourceforge.net Tue Dec 12 13:52:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 04:52:47 -0800 Subject: [ python-Bugs-1613130 ] str.split creates new string even if pattern not found Message-ID: Bugs item #1613130, was opened at 2006-12-11 14:03 Message generated for change (Settings changed) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&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: Open Resolution: None Priority: 5 Private: No Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: str.split creates new string even if pattern not found Initial Comment: Hello, Several string methods avoid allocating a new string when the operation result is trivially the same as one of the parameters (e.g. replacing a non-existing substring). However, split() does not exhibit this optimization, it always constructs a new string even if no splitting occurs: $ python Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> s = "abcde" * 2 >>> id(s) 3084139400L >>> id(str(s)) 3084139400L >>> id("" + s) 3084139400L >>> id(s.strip()) 3084139400L >>> id(s.replace("g", "h")) 3084139400L >>> [id(x) for x in s.partition("h")] [3084139400L, 3084271768L, 3084271768L] >>> [id(x) for x in s.split("h")] [3084139360L] ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2006-12-12 12:35 Message: Logged In: YES user_id=133955 Originator: YES Ok, I did a patch which partially adds the optimization (the patch is at home, I can't post it right now). I have a few questions though: - there is a USE_FAST flag which can bring some speedups when a multicharacter separator is used; however, it is not enabled by default, is there a reason for this? - where and by whom is maintained stringbench.py, so that I can propose additional tests for it (namely, tests for unmatched split())? - split() implementation is duplicated between str and unicode (the unicode versions having less optimizations), would it be useful to "stringlib'ify" split()? - rsplit() does quite similar things as split(), has anyone tried to factor similar parts? do you see any caveats doing so? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470 From noreply at sourceforge.net Tue Dec 12 17:21:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 08:21:22 -0800 Subject: [ python-Bugs-1613130 ] str.split creates new string even if pattern not found Message-ID: Bugs item #1613130, was opened at 2006-12-11 13:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&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: Open Resolution: None Priority: 5 Private: No Submitted By: Antoine Pitrou (pitrou) >Assigned to: Fredrik Lundh (effbot) Summary: str.split creates new string even if pattern not found Initial Comment: Hello, Several string methods avoid allocating a new string when the operation result is trivially the same as one of the parameters (e.g. replacing a non-existing substring). However, split() does not exhibit this optimization, it always constructs a new string even if no splitting occurs: $ python Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> s = "abcde" * 2 >>> id(s) 3084139400L >>> id(str(s)) 3084139400L >>> id("" + s) 3084139400L >>> id(s.strip()) 3084139400L >>> id(s.replace("g", "h")) 3084139400L >>> [id(x) for x in s.partition("h")] [3084139400L, 3084271768L, 3084271768L] >>> [id(x) for x in s.split("h")] [3084139360L] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-12 16:21 Message: Logged In: YES user_id=849994 Originator: NO Sounds like this is best assigned to Fredrik. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2006-12-12 11:35 Message: Logged In: YES user_id=133955 Originator: YES Ok, I did a patch which partially adds the optimization (the patch is at home, I can't post it right now). I have a few questions though: - there is a USE_FAST flag which can bring some speedups when a multicharacter separator is used; however, it is not enabled by default, is there a reason for this? - where and by whom is maintained stringbench.py, so that I can propose additional tests for it (namely, tests for unmatched split())? - split() implementation is duplicated between str and unicode (the unicode versions having less optimizations), would it be useful to "stringlib'ify" split()? - rsplit() does quite similar things as split(), has anyone tried to factor similar parts? do you see any caveats doing so? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613130&group_id=5470 From noreply at sourceforge.net Tue Dec 12 21:52:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 12:52:20 -0800 Subject: [ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often Message-ID: Bugs item #1607951, was opened at 2006-12-03 12:28 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.Maildir re-reads directory too often Initial Comment: [forwarded from http://bugs.debian.org/401395] Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir. _refresh should stat each of the two directories first to see if they changed. This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&group_id=5470 From noreply at sourceforge.net Tue Dec 12 21:55:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 12:55:29 -0800 Subject: [ python-Bugs-1600152 ] mailbox: Maildir.get_folder does not inherit factory Message-ID: Bugs item #1600152, was opened at 2006-11-20 22:33 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tetsuya Takatsuru (taka2ru) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: Maildir.get_folder does not inherit factory Initial Comment: mailbox.Maildir.get_folder does not inherit _factory. >>> import mailbox >>> >>> mbox = mailbox.Maildir('/home/xxx/Maildir', mailbox.MaildirMessage) >>> >>> subfolder = mbox.get_folder(mbox.list_folders()[0]) >>> >>> for key, mail in subfolder.iteritems(): >>> print mail.__class__ >>> break from this example, i got the following output: rfc822.Message 'mailbox.MaildirMessage' should be gotten instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&group_id=5470 From noreply at sourceforge.net Tue Dec 12 21:56:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 12:56:06 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Tue Dec 12 21:58:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 12:58:43 -0800 Subject: [ python-Bugs-1613573 ] xmlrpclib ServerProxy uses old httplib interface Message-ID: Bugs item #1613573, was opened at 2006-12-11 18:17 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Brown (mattgbrown) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib ServerProxy uses old httplib interface Initial Comment: The ServerProxy class of the xmlrpclib module uses the old style HTTP / HTTPS classes of the httplib module rather than the newer HTTPConnection and HTTPConnection classes. The practical result of this is that xmlrpc connections are not able to make use of HTTP/1.1 functionality. Please update the xmlrpclib module to use the newer API provided by httplib so that the advanced functionality of HTTP/1.1 is available. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 15:58 Message: Logged In: YES user_id=11375 Originator: NO Can you provide a patch to make this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613573&group_id=5470 From noreply at sourceforge.net Tue Dec 12 22:04:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 13:04:27 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Wed Dec 13 01:24:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 16:24:55 -0800 Subject: [ python-Bugs-1614387 ] AttributesImpl does not implement __contains__ on Linux Message-ID: Bugs item #1614387, was opened at 2006-12-13 00:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&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: XML Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Briggs (jrbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: AttributesImpl does not implement __contains__ on Linux Initial Comment: Hi there Had an odd error trying to run a utility called SVGMath: File "/home/jason/downloads/SVGMath-0.3.1/svgmath/mathconfig.py", line 54, in startElement elif u"afm" in attributes: File "/usr/lib/python2.5/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__ return self._attrs[name] KeyError: 0 It appears that AttributesImpl in the sax package (xmlreader.py) doesn't implement __contains__, so the 'in' operator throws an error. This is on Kubuntu/Linux, so I'm not sure if it's distro-specific or all Linux versions of Python. In any case, if you add: def __contains__(self, name): return self._attrs.has_key(name) to AttributesImpl in xmlreader.py (as per the Windows version of Python), the problem goes away. Kind regards Jason ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&group_id=5470 From noreply at sourceforge.net Wed Dec 13 02:48:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 17:48:22 -0800 Subject: [ python-Bugs-1614429 ] dict throwing inaccurate KeyError on small tuple keys Message-ID: Bugs item #1614429, was opened at 2006-12-13 02:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614429&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: toidinamai (toidinamai) Assigned to: Nobody/Anonymous (nobody) Summary: dict throwing inaccurate KeyError on small tuple keys Initial Comment: When using tuples of length one as keys for the builtin dictionary the Python runtime raises an inaccurate KeyError exception that makes some errors hard to find: Python 2.5 (r25:51908, Dec 12 2006, 18:39:30) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> {"foo":"bar"}[("foo",)] Traceback (most recent call last): File "", line 1, in KeyError: 'foo' Also the error messages for the empty tuple and None are indistinguishable: Python 2.5 (r25:51908, Dec 12 2006, 18:39:30) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> {None:"bar"}[()] Traceback (most recent call last): File "", line 1, in KeyError >>> {():"bar"}[None] Traceback (most recent call last): File "", line 1, in KeyError This also seems to be the case for earlier versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614429&group_id=5470 From noreply at sourceforge.net Wed Dec 13 03:46:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 18:46:00 -0800 Subject: [ python-Bugs-1614429 ] dict throwing inaccurate KeyError on small tuple keys Message-ID: Bugs item #1614429, was opened at 2006-12-12 20:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614429&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: Duplicate Priority: 5 Private: No Submitted By: toidinamai (toidinamai) Assigned to: Nobody/Anonymous (nobody) Summary: dict throwing inaccurate KeyError on small tuple keys Initial Comment: When using tuples of length one as keys for the builtin dictionary the Python runtime raises an inaccurate KeyError exception that makes some errors hard to find: Python 2.5 (r25:51908, Dec 12 2006, 18:39:30) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> {"foo":"bar"}[("foo",)] Traceback (most recent call last): File "", line 1, in KeyError: 'foo' Also the error messages for the empty tuple and None are indistinguishable: Python 2.5 (r25:51908, Dec 12 2006, 18:39:30) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> {None:"bar"}[()] Traceback (most recent call last): File "", line 1, in KeyError >>> {():"bar"}[None] Traceback (most recent call last): File "", line 1, in KeyError This also seems to be the case for earlier versions of Python. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-12 21:46 Message: Logged In: YES user_id=80475 Originator: NO This is a duplicate of bug #1576657 when Georg just fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614429&group_id=5470 From noreply at sourceforge.net Wed Dec 13 04:02:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Dec 2006 19:02:21 -0800 Subject: [ python-Bugs-1614460 ] python-logging compatability with Zope. Message-ID: Bugs item #1614460, was opened at 2006-12-13 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Hookway (shookway) Assigned to: Nobody/Anonymous (nobody) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 From noreply at sourceforge.net Wed Dec 13 14:02:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Dec 2006 05:02:42 -0800 Subject: [ python-Bugs-1057048 ] subprocess works poorly on Windows with Python 2.3 Message-ID: Bugs item #1057048, was opened at 2004-10-29 21:24 Message generated for change (Comment added) made by chas17360 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057048&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: Python Library Group: Python 2.4 Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess works poorly on Windows with Python 2.3 Initial Comment: My understanding was that subprocess.py was supposed to be backwards compatible with at least Python 2.3 if not 2.2. Wanting subprocess and backwards compatibility, I grabbed the subprocess.py from 2.4b1, changed the import if so that win32api was used (since I had no _subprocess library!) and found several problems, of which this is one (one per bug report): If the executable has a space in its path name (as is standard on Windows) and command-line arguments, things fail miserably: from subprocess import * Popen('"C:\\Program Files\\ds9\\xpaget" ds9 mode') produces an error that C:\Program cannot be run. Clearly the double quoting isn't making it through Popen. Note that this runs just fine if there are no command line arguments, i.e. this works: Popen('"C:\\Program Files\\ds9\\xpaget"') Note that this same bug also exists in os.popen3, so you may have inherited it. This bug does NOT occur on a unix build on MacOS X. ---------------------------------------------------------------------- Comment By: chas17360 (chas17360) Date: 2006-12-13 13:02 Message: Logged In: YES user_id=1667498 Originator: NO I may have found a related problem: The following appears in function list2cmdline(): elif c == '"': # Double backspaces. result.append('\\' * len(bs_buf)*2) bs_buf = [] result.append('\\"') i.e. the character(s) being checked is a double quote, but the comment states 'Double backspaces'. The code as it is (using Python25) causes a problem when trying to perform a Windows XP copy on a file with whitespace in it's name. The problem does not occur if the double quote in the code above is replaced by 2 back ticks. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2004-11-17 22:03 Message: Logged In: YES user_id=431773 I tried to follow up on this and today I cannot get it to fail on my system. I suggest suspending or closing the bug report. If I figure out what was going on and it still seems to be a bug, I'll reopen or file a new report. Sorry for the trouble (and thanks for fixing the problem with opening console windows on Windows). ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-11-07 16:18 Message: Logged In: YES user_id=344921 I don't have a "c:\program files" directory on my system, since it's a Swedish version of Windows. I've tested with "c:\program\internet explorer\iexplore.exe" instead, but cannot reproduce the problem: Not with subprocess with 2.4 or 2.3, and not with os.popen3 either. For example, I've tried: w, r, x = os.popen3('"c:\\program\\internet explorer\iexplore.exe" www.abc.se') Please test and see if you can reproduce the problem with Internet Explorer. As far as I know, it should be safe to install 2.4b1 without trashing the 2.3 installation. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2004-11-03 19:11 Message: Logged In: YES user_id=431773 I am using Windows 2000 Professional. I am not using command.com, at least not that I know of. I'm running my program from PythonWin or IDLE (most often the former). Can I safely install 2.4b1 and not trash my 2.3 install? If so, I'll give it a go. (I know this works on Mac and unix, but have no idea how it works on Windows). Another possibility is to test the results at your end by editing subprocess.py to toggle that flag that makes win32api be used instead of _subprocess. Then launching any app using an explicit path should show the problem (or not), since they are all in C:\\Program Files\... ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-10-31 07:05 Message: Logged In: YES user_id=344921 Are you running on Windows 9X, or using command.com? If you are using shell=False (as in your example), subprocess doesn't change the argument string in any way: It is passed directly to CreateProcess. Can you confirm that the problem only exists with Python 2.3, and not with 2.4? In that case, it might be a bug in win32api:s CreateProcess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057048&group_id=5470 From noreply at sourceforge.net Wed Dec 13 14:38:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Dec 2006 05:38:37 -0800 Subject: [ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often Message-ID: Bugs item #1607951, was opened at 2006-12-03 12:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.Maildir re-reads directory too often Initial Comment: [forwarded from http://bugs.debian.org/401395] Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir. _refresh should stat each of the two directories first to see if they changed. This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-13 08:38 Message: Logged In: YES user_id=11375 Originator: NO By stat()'ing the directories, do you mean checking the mtime? I think this isn't safe because of the limited resolution of mtime on filesystems; ext3 seems to have a 1-second resolution for mtime, for example. This means that _refresh() might read a directory, and if some other process adds or deletes a message in the same second, _refresh() couldn't detect the change. Is there some other property of directories that could be used for a more reliable check? The attached patch implements checking of mtime, but I don't recommend applying it; it causes the test suite in test_mailbox.py to break all over the place, because the process modifies mailboxes so quickly that the mtime check doesn't notice the process's own changes. I'll wait a bit for any alternative suggestion, and then close this bug as "won't fix". File Added: mailbox-mtime.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&group_id=5470 From noreply at sourceforge.net Wed Dec 13 22:20:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Dec 2006 13:20:55 -0800 Subject: [ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows Message-ID: Bugs item #1615275, was opened at 2006-12-13 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&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: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: hirzel (hirzel) Assigned to: Nobody/Anonymous (nobody) Summary: tempile.TemporaryFile differences between linux and windows Initial Comment: This bug came up when trying to write a numpy array to a tempfile.TemporaryFile() using the numpy 'tofile' method on windows using python 2.4. with a numpy array 'a', and a TemporaryFile 'f', on windows: >>> a.tofile(f) throws an IOError, where on Linux it does not. On windows, you must use a.tofile(f.file) The cause of this difference is that in windows, tempfile.TemporaryFile() returns that has a 'file' attribute of , whereas in linux tempfile.TemporaryFile() returns and there is no 'file' attribute. Ideally, the windows version would align with linux, and the module documentation and TemporaryFile() would return a . If this is not possible, it seems like the linux version and docs should be changed to match the windows version to align cross-platform behavior. At least, that seems to be the shared opinion of this thread from the mailing list: numpy-discussion. http://www.mail-archive.com/numpy-discussion at scipy.org/msg00271.html To my knowledge, while platform differences in tempfile have been reported in the past, this one has not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 From noreply at sourceforge.net Thu Dec 14 00:21:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Dec 2006 15:21:17 -0800 Subject: [ python-Bugs-1503765 ] logger.config problems with comma separated lists Message-ID: Bugs item #1503765, was opened at 2006-06-10 01:04 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&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: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: cuppatea (cuppatea) Assigned to: Vinay Sajip (vsajip) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-12-14 00:21 Message: Logged In: YES user_id=1326842 Originator: NO Shouldn't this patch and patch #1609407 also go to the release25-maint branch? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-11 15:42 Message: Logged In: YES user_id=308438 Originator: NO Applied a modified version of this patch to SVN - trunk and release24-maint. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:20 Message: Logged In: YES user_id=849994 Attaching a real patch and assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 From noreply at sourceforge.net Thu Dec 14 01:21:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Dec 2006 16:21:37 -0800 Subject: [ python-Bugs-1615376 ] subprocess doesn't handle SIGPIPE Message-ID: Bugs item #1615376, was opened at 2006-12-14 00:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615376&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess doesn't handle SIGPIPE Initial Comment: subprocess keeps other side of child pipe open, making use of SIGPIPE to terminate writers in a pipeline not possible. This is probably a matter of documentation or providing a method to link up processes, as the parent end of the pipe must remain open until it is connected to the next process in the pipeline. An option to enable sigpipe in child would be nice. Simple example attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615376&group_id=5470 From noreply at sourceforge.net Thu Dec 14 01:30:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Dec 2006 16:30:19 -0800 Subject: [ python-Bugs-1611131 ] \b in unicode regex gives strange results Message-ID: Bugs item #1611131, was opened at 2006-12-07 23:44 Message generated for change (Comment added) made by akaihola You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&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: Regular Expressions Group: Python 2.5 >Status: Deleted >Resolution: Invalid Priority: 5 Private: No Submitted By: akaihola (akaihola) Assigned to: Gustavo Niemeyer (niemeyer) Summary: \b in unicode regex gives strange results Initial Comment: The problem: This doesn't give a match: >>> re.match(r'?\b', '? ', re.UNICODE) This works ok and gives a match: >>> re.match(r'.\b', '? ', re.UNICODE) Both of these work as well: >>> re.match(r'a\b', 'a ', re.UNICODE) >>> re.match(r'.\b', 'a ', re.UNICODE) Docs say \b is defined as an empty string between \w and \W. These do match accordingly: >>> re.match(r'\w', '?', re.UNICODE) >>> re.match(r'\w', 'a', re.UNICODE) >>> re.match(r'\W', ' ', re.UNICODE) So something strange happens in my first example, and I can't help but assume it's a bug. ---------------------------------------------------------------------- >Comment By: akaihola (akaihola) Date: 2006-12-14 02:30 Message: Logged In: YES user_id=1432932 Originator: YES Ok so this does work: >>> re.match(ur'?\b', u'? ', re.UNICODE) If I understand correctly, I was comparing UTF-8 encoded strings in my examples (my Ubuntu is UTF-8 by default) and regex special operators just don't work in that domain. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-08 22:51 Message: Logged In: YES user_id=849994 Originator: NO FWIW, the first example works fine for me with and without Unicode strings. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-08 19:18 Message: Logged In: YES user_id=21627 Originator: NO Notice that the re.UNICODE flag is only meaningful if you are using Unicode strings; in the examples you give, you are using byte strings. Please re-test with Unicode strings both as the expression and as the string to match. ---------------------------------------------------------------------- Comment By: akaihola (akaihola) Date: 2006-12-08 00:18 Message: Logged In: YES user_id=1432932 Originator: YES As a work-around I currently use a regex like r'?(?=\W)'. Seems to work ok. Also, the \b problem doesn't seem to exist in the \W\w case, i.e. at the beginning of words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&group_id=5470 From noreply at sourceforge.net Thu Dec 14 20:09:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Dec 2006 11:09:32 -0800 Subject: [ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often Message-ID: Bugs item #1607951, was opened at 2006-12-03 12:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.Maildir re-reads directory too often Initial Comment: [forwarded from http://bugs.debian.org/401395] Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir. _refresh should stat each of the two directories first to see if they changed. This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-14 14:09 Message: Logged In: YES user_id=11375 Originator: NO Stray thought: would it help if the patch stored the (mtime - 1sec) instead of the mtime? Successive calls in the same second would then always re-read the directories, but once the clock ticks to the next second, re-reads would only occur if the directories have actually changed. The check would be 'if new_mtime > self._new_mtime' instead of '=='. Is this sort of mtime-based checking reliable on remote filesystems such as NFS? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-13 08:38 Message: Logged In: YES user_id=11375 Originator: NO By stat()'ing the directories, do you mean checking the mtime? I think this isn't safe because of the limited resolution of mtime on filesystems; ext3 seems to have a 1-second resolution for mtime, for example. This means that _refresh() might read a directory, and if some other process adds or deletes a message in the same second, _refresh() couldn't detect the change. Is there some other property of directories that could be used for a more reliable check? The attached patch implements checking of mtime, but I don't recommend applying it; it causes the test suite in test_mailbox.py to break all over the place, because the process modifies mailboxes so quickly that the mtime check doesn't notice the process's own changes. I'll wait a bit for any alternative suggestion, and then close this bug as "won't fix". File Added: mailbox-mtime.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&group_id=5470 From noreply at sourceforge.net Thu Dec 14 21:18:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Dec 2006 12:18:50 -0800 Subject: [ python-Bugs-1600152 ] mailbox: Maildir.get_folder does not inherit factory Message-ID: Bugs item #1600152, was opened at 2006-11-20 22:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&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: Python Library Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Tetsuya Takatsuru (taka2ru) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: Maildir.get_folder does not inherit factory Initial Comment: mailbox.Maildir.get_folder does not inherit _factory. >>> import mailbox >>> >>> mbox = mailbox.Maildir('/home/xxx/Maildir', mailbox.MaildirMessage) >>> >>> subfolder = mbox.get_folder(mbox.list_folders()[0]) >>> >>> for key, mail in subfolder.iteritems(): >>> print mail.__class__ >>> break from this example, i got the following output: rfc822.Message 'mailbox.MaildirMessage' should be gotten instead. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-14 15:18 Message: Logged In: YES user_id=11375 Originator: NO Thanks for your report. This bug has already been reported as #1569790, and has been fixed in both the trunk and 25-maint branches. Please see that bug for a patch that fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&group_id=5470 From noreply at sourceforge.net Fri Dec 15 00:51:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Dec 2006 15:51:29 -0800 Subject: [ python-Bugs-1616109 ] IA64/AMD64/x64 confusion Message-ID: Bugs item #1616109, was opened at 2006-12-14 21:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 From noreply at sourceforge.net Fri Dec 15 06:15:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Dec 2006 21:15:06 -0800 Subject: [ python-Bugs-1571112 ] simple moves freeze IDLE Message-ID: Bugs item #1571112, was opened at 2006-10-05 00:46 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Douglas W. Goodall (douglas_goodall) Assigned to: Kurt B. Kaiser (kbk) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-15 00:15 Message: Logged In: YES user_id=149084 Originator: NO Rev 53042 Also, it appears that os.__all__ is fixed. Thanks for the analysis! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-12-09 12:33 Message: Logged In: YES user_id=1330769 Originator: NO This cause for this bug is an endless loop in AutoCompleteWindow.py, line 121: 114 selstart = self.completions[cursel] [snip...] 121 while cursel > 0 and selstart[:i] <= self.completions[cursel-1]: 122 i += 1 123 newstart = selstart[:i] The case where this loop becomes endless only arises when the same completion item appears twice in the completions list, thus self.completions[cursel-1] and self.completions[cursel] are identical. This happens with the os module because spawnv and spawnve appear twice in os.__all__. Solution: 1) Fix the potentially endless loop (add a bound for i) 2) Remove identical completion items from the completions list (its a bug anyways) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-08 13:47 Message: Logged In: YES user_id=580910 As an additional data point: this seems to work just fine on Mac OS X. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-07 23:16 Message: Logged In: YES user_id=80475 I can reproduce this in Py2.5 final. This may be a TkInter bug and not unique to IDLE or to Windows. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 12:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 From noreply at sourceforge.net Fri Dec 15 06:30:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Dec 2006 21:30:14 -0800 Subject: [ python-Bugs-1599931 ] Immediate Crash on Open Message-ID: Bugs item #1599931, was opened at 2006-11-20 14:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&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: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Farhymn (farhymn) >Assigned to: Kurt B. Kaiser (kbk) Summary: Immediate Crash on Open Initial Comment: Python 2.5 IDLE crashes -immediately- upon open, leaving enough time to hold down the enter button on the executable and only have the pythonw process show up one-at-a-time. This is version specific, as 2.4 Final worked fine. Now all applications cannot run. I made sure to uninstall 2.4 before installing 2.5, so it isn't a version conflict (as far as I can tell). Running Windows XP SP2 on an HP Laptop (paviliion dv4000) and am attempting to run the program OpenRPG+. Program can be provided for replication of test as necessary. Duplicate processes are not observed in Windows Task Manager and a complete uninstallation and installation of the Python 2.5 language provides the same unknown error. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-15 00:30 Message: Logged In: YES user_id=149084 Originator: NO I'm sorry, I can't understand your report. Please tell me exactly how you are starting IDLE (using the icon? using a command window?) What does OpenRPG+ have to do with it, are you calling it along with IDLE? If so, please give me the command line and a url for the program. What does your "edit" have to do with the problem? The second number is illegal, because although it's coded as an octal (starts with 0) it has characters greater than 7 in it. Fix either of those issues, and it's fine. ---------------------------------------------------------------------- Comment By: Farhymn (farhymn) Date: 2006-11-20 14:53 Message: Logged In: YES user_id=1650037 Originator: YES (edit) Forgot to mention that the problem is pythonw.exe specific as well. Python DOS runs fine, I can only get it to register a token error by typing in the following at the prompt: 1234816587613289741-0152872349817230987 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 From noreply at sourceforge.net Fri Dec 15 07:54:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Dec 2006 22:54:11 -0800 Subject: [ python-Bugs-1612262 ] Class Browser doesn't show internal classes Message-ID: Bugs item #1612262, was opened at 2006-12-09 12:38 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612262&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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Class Browser doesn't show internal classes Initial Comment: If I define a class within a class, like this: class A: class B: pass def foo(self): pass The class browser shows that A contains foo, but it doesn't show B at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612262&group_id=5470 From noreply at sourceforge.net Fri Dec 15 09:06:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 00:06:13 -0800 Subject: [ python-Bugs-1614460 ] python-logging compatability with Zope. Message-ID: Bugs item #1614460, was opened at 2006-12-13 03:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Hookway (shookway) >Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 08:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 From noreply at sourceforge.net Fri Dec 15 14:17:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 05:17:33 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Fri Dec 15 15:06:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 06:06:32 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 09:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Fri Dec 15 15:30:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 06:30:41 -0800 Subject: [ python-Bugs-1616422 ] Wrong pathname value in logging output Message-ID: Bugs item #1616422, was opened at 2006-12-15 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=105470&aid=1616422&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tekkaman (simleo) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong pathname value in logging output Initial Comment: When trying to log caller pathname information, instead of the actual caller's name I get the full name of the logging module source file: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') /usr/lib/python2.4/logging/__init__.py >>> I've been discussing this on comp.lang.python and the suspect arised that this has something to do with a symlink in the path leading to the module source file (I have a lib -> lib64 symlink on my system). To verify this I copied the entire logging directory into my home dir and retried. This is what I got: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') >>> Additional info: Python Version: 2.4.3 OS: Gentoo Linux 2.6.17-r8 CPU: AMD Turion(tm) 64 Mobile Technology sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/dbus', '/usr/lib64/python2.4/site-packages/gtk-2.0'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470 From noreply at sourceforge.net Fri Dec 15 17:15:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 08:15:27 -0800 Subject: [ python-Bugs-1593751 ] poor urllib error handling Message-ID: Bugs item #1593751, was opened at 2006-11-09 22:04 Message generated for change (Comment added) made by robertwinder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&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: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: poor urllib error handling Initial Comment: I set up a simple server that returns an empty response. >>> from socket import * >>> s = socket() >>> s.bind(("", 9999)) >>> while 1: x, c = s.accept(); print c; x.recv(1000); x.close() ... Pointing urllib at this gives a traceback: Python 2.6a0 (trunk:52099M, Oct 3 2006, 09:59:17) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.urlopen('http://localhost:9999/') Traceback (most recent call last): File "", line 1, in File "/home/guido/p/Lib/urllib.py", line 82, in urlopen return opener.open(url) File "/home/guido/p/Lib/urllib.py", line 190, in open return getattr(self, name)(url) File "/home/guido/p/Lib/urllib.py", line 334, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 351, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/home/guido/p/Lib/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/home/guido/p/Lib/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' >>> I can repeat this with 2.2.3 and 2.4.3 as well (don't have 2.3 around for testing). The direct cause of the problem is that h.getfile() on line 329 of urllib.py (in head of trunk) returns None. ---------------------------------------------------------------------- Comment By: Robert Winder (robertwinder) Date: 2006-12-15 17:15 Message: Logged In: YES user_id=195085 Originator: NO Same error handling with 2.3. Suggested fix doesn't work and gives. AttributeError: addinfourl instance has no attribute 'read' ---------------------------------------------------------------------- Comment By: Robert Carr (racarr) Date: 2006-12-05 16:26 Message: Logged In: YES user_id=1649655 Originator: NO Fix? Index: urllib.py =================================================================== --- urllib.py (revision 52918) +++ urllib.py (working copy) @@ -895,8 +895,10 @@ def __init__(self, fp): self.fp = fp - self.read = self.fp.read - self.readline = self.fp.readline + try: + self.read = self.fp.read + self.readline = self.fp.readline + except: print "File handler is none" if hasattr(self.fp, "readlines"): self.readlines = self.fp.readlines if hasattr(self.fp, "fileno"): self.fileno = self.fp.fileno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&group_id=5470 From noreply at sourceforge.net Fri Dec 15 18:13:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 09:13:05 -0800 Subject: [ python-Bugs-1614460 ] python-logging compatability with Zope. Message-ID: Bugs item #1614460, was opened at 2006-12-13 03:02 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: Python Library Group: Python 2.4 >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Simon Hookway (shookway) Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 17:13 Message: Logged In: YES user_id=308438 Originator: NO Yes, a fix was applied a while ago. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 08:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 From noreply at sourceforge.net Fri Dec 15 18:20:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 09:20:36 -0800 Subject: [ python-Bugs-1616422 ] Wrong pathname value in logging output Message-ID: Bugs item #1616422, was opened at 2006-12-15 14:30 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&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: Python Library Group: Python 2.4 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Tekkaman (simleo) >Assigned to: Vinay Sajip (vsajip) Summary: Wrong pathname value in logging output Initial Comment: When trying to log caller pathname information, instead of the actual caller's name I get the full name of the logging module source file: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') /usr/lib/python2.4/logging/__init__.py >>> I've been discussing this on comp.lang.python and the suspect arised that this has something to do with a symlink in the path leading to the module source file (I have a lib -> lib64 symlink on my system). To verify this I copied the entire logging directory into my home dir and retried. This is what I got: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') >>> Additional info: Python Version: 2.4.3 OS: Gentoo Linux 2.6.17-r8 CPU: AMD Turion(tm) 64 Mobile Technology sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/dbus', '/usr/lib64/python2.4/site-packages/gtk-2.0'] ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 17:20 Message: Logged In: YES user_id=308438 Originator: NO Sorry, why is this wrong? You are making the logging call from an interactive prompt - so you would expect to get the pathname of , would you not? I get the same output on Windows where the only logging module is the one which is part of the standard Python installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470 From noreply at sourceforge.net Fri Dec 15 22:09:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 13:09:29 -0800 Subject: [ python-Bugs-1616726 ] Vague description of generator close() method Message-ID: Bugs item #1616726, was opened at 2006-12-15 13:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616726&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: 5 Private: No Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: Vague description of generator close() method Initial Comment: In section 7 of "What's New in Python 2.5" the subsection on the close() generator method states: close() raises a new GeneratorExit exception inside the generator to terminate the iteration. On receiving this exception, the generator's code must either raise GeneratorExit or StopIteration; catching the exception and doing anything else is illegal and will trigger a RuntimeError. This suggests that if a generator raises a new exception that is neither a GeneratorExit nor StopIteration a RuntimeError is raised. But this is not the case according to Part 4 of PEP 342's "Specification Summary": If the generator raises any other exception, it is propagated to the caller. The Python 2.5 interpreter is consistent with PEP 342: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> def raise_wrong_exception(): ... try: ... yield 1 ... yield 2 ... except GeneratorExit: ... raise TypeError("Where is the RuntimeError?") ... >>> i=raise_wrong_exception() >>> i.next() 1 >>> i.close() Traceback (most recent call last): File "", line 1, in File "", line 6, in raise_wrong_exception TypeError: Where is the RuntimeError? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616726&group_id=5470 From noreply at sourceforge.net Fri Dec 15 23:23:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Dec 2006 14:23:51 -0800 Subject: [ python-Bugs-1614387 ] AttributesImpl does not implement __contains__ on Linux Message-ID: Bugs item #1614387, was opened at 2006-12-13 00:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&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: XML Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Briggs (jrbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: AttributesImpl does not implement __contains__ on Linux Initial Comment: Hi there Had an odd error trying to run a utility called SVGMath: File "/home/jason/downloads/SVGMath-0.3.1/svgmath/mathconfig.py", line 54, in startElement elif u"afm" in attributes: File "/usr/lib/python2.5/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__ return self._attrs[name] KeyError: 0 It appears that AttributesImpl in the sax package (xmlreader.py) doesn't implement __contains__, so the 'in' operator throws an error. This is on Kubuntu/Linux, so I'm not sure if it's distro-specific or all Linux versions of Python. In any case, if you add: def __contains__(self, name): return self._attrs.has_key(name) to AttributesImpl in xmlreader.py (as per the Windows version of Python), the problem goes away. Kind regards Jason ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 22:23 Message: Logged In: YES user_id=849994 Originator: NO It looks like the xmlreader.py doesn't come from the Python distribution, but from the PyXML library, which is maintained elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&group_id=5470 From noreply at sourceforge.net Sat Dec 16 09:52:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 00:52:28 -0800 Subject: [ python-Bugs-1616109 ] IA64/AMD64/x64 confusion Message-ID: Bugs item #1616109, was opened at 2006-12-15 00:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&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: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 09:52 Message: Logged In: YES user_id=21627 Originator: NO I don't see a need to change the page. It says clearly that the ia64 binary is for "Itanium". If you thought that you had an Itanium processor, there is not much we could do for you. I refuse to call the architecture or the binary "EM64T", "x64", or "x86-64". AMD has invented the architecture, so they get to name it. They originally called it x86-64, but later requested that people call it AMD64, so that's what we do. Notice that Microsoft calls the operating system you are running "XP x64 Edition", not "XP 64". They also offer "XP 64-bit Itanium Edition". So Windows users just have to learn that "64-bit Windows" is not a precise architecture specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 From noreply at sourceforge.net Sat Dec 16 12:05:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 03:05:43 -0800 Subject: [ python-Bugs-1614387 ] AttributesImpl does not implement __contains__ on Linux Message-ID: Bugs item #1614387, was opened at 2006-12-13 00:24 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&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: XML >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jason Briggs (jrbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: AttributesImpl does not implement __contains__ on Linux Initial Comment: Hi there Had an odd error trying to run a utility called SVGMath: File "/home/jason/downloads/SVGMath-0.3.1/svgmath/mathconfig.py", line 54, in startElement elif u"afm" in attributes: File "/usr/lib/python2.5/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__ return self._attrs[name] KeyError: 0 It appears that AttributesImpl in the sax package (xmlreader.py) doesn't implement __contains__, so the 'in' operator throws an error. This is on Kubuntu/Linux, so I'm not sure if it's distro-specific or all Linux versions of Python. In any case, if you add: def __contains__(self, name): return self._attrs.has_key(name) to AttributesImpl in xmlreader.py (as per the Windows version of Python), the problem goes away. Kind regards Jason ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 22:23 Message: Logged In: YES user_id=849994 Originator: NO It looks like the xmlreader.py doesn't come from the Python distribution, but from the PyXML library, which is maintained elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&group_id=5470 From noreply at sourceforge.net Sat Dec 16 12:05:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 03:05:58 -0800 Subject: [ python-Bugs-1614387 ] AttributesImpl does not implement __contains__ on Linux Message-ID: Bugs item #1614387, was opened at 2006-12-13 00:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&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: XML Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jason Briggs (jrbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: AttributesImpl does not implement __contains__ on Linux Initial Comment: Hi there Had an odd error trying to run a utility called SVGMath: File "/home/jason/downloads/SVGMath-0.3.1/svgmath/mathconfig.py", line 54, in startElement elif u"afm" in attributes: File "/usr/lib/python2.5/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__ return self._attrs[name] KeyError: 0 It appears that AttributesImpl in the sax package (xmlreader.py) doesn't implement __contains__, so the 'in' operator throws an error. This is on Kubuntu/Linux, so I'm not sure if it's distro-specific or all Linux versions of Python. In any case, if you add: def __contains__(self, name): return self._attrs.has_key(name) to AttributesImpl in xmlreader.py (as per the Windows version of Python), the problem goes away. Kind regards Jason ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-16 11:05 Message: Logged In: YES user_id=849994 Originator: NO Reported in the PyXML tracker. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 22:23 Message: Logged In: YES user_id=849994 Originator: NO It looks like the xmlreader.py doesn't come from the Python distribution, but from the PyXML library, which is maintained elsewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&group_id=5470 From noreply at sourceforge.net Sat Dec 16 12:40:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 03:40:05 -0800 Subject: [ python-Bugs-1616109 ] IA64/AMD64/x64 confusion Message-ID: Bugs item #1616109, was opened at 2006-12-14 21:51 Message generated for change (Comment added) made by dreamcatcher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&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: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. ---------------------------------------------------------------------- >Comment By: Sidnei da Silva (dreamcatcher) Date: 2006-12-16 09:40 Message: Logged In: YES user_id=438768 Originator: YES I understand that calling it AMD64 is the 'correct' thing. However the end user will say 'but I have an Intel processor, not AMD'. I'm not asking for a rename, just for a note on the download page. You shouldn't expect the users downloading this to know the difference between 'Itanium' vs 'AMD64' vs 'EM64T'. They probably, though, know the difference between 'XP Itanium Edition' and 'XP x64 Edition'. Since the 'AMD64' installer will work on 'XP x64' no matter if the processor is AMD64 or EM64T, I think the page should at least say something like: 'If you are running XP x64, 2003 x64 (does that exist?) or (insert equivalent Vista here) then the installer you are looking for is the 'AMD64' one.' What do you think? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 06:52 Message: Logged In: YES user_id=21627 Originator: NO I don't see a need to change the page. It says clearly that the ia64 binary is for "Itanium". If you thought that you had an Itanium processor, there is not much we could do for you. I refuse to call the architecture or the binary "EM64T", "x64", or "x86-64". AMD has invented the architecture, so they get to name it. They originally called it x86-64, but later requested that people call it AMD64, so that's what we do. Notice that Microsoft calls the operating system you are running "XP x64 Edition", not "XP 64". They also offer "XP 64-bit Itanium Edition". So Windows users just have to learn that "64-bit Windows" is not a precise architecture specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 From noreply at sourceforge.net Sat Dec 16 13:09:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 04:09:51 -0800 Subject: [ python-Bugs-1616109 ] IA64/AMD64/x64 confusion Message-ID: Bugs item #1616109, was opened at 2006-12-15 00:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&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: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 13:09 Message: Logged In: YES user_id=21627 Originator: NO I would like to avoid adding more text. It is already too much text. Also, I outright refuse to use any of the official Intel terminology on an official webpage (and, as you say, EM64T is not the current name that Intel gives this anymore; the brain washing goes on as they called "Intel 64" now, just as if they invented it). ---------------------------------------------------------------------- Comment By: Sidnei da Silva (dreamcatcher) Date: 2006-12-16 12:40 Message: Logged In: YES user_id=438768 Originator: YES I understand that calling it AMD64 is the 'correct' thing. However the end user will say 'but I have an Intel processor, not AMD'. I'm not asking for a rename, just for a note on the download page. You shouldn't expect the users downloading this to know the difference between 'Itanium' vs 'AMD64' vs 'EM64T'. They probably, though, know the difference between 'XP Itanium Edition' and 'XP x64 Edition'. Since the 'AMD64' installer will work on 'XP x64' no matter if the processor is AMD64 or EM64T, I think the page should at least say something like: 'If you are running XP x64, 2003 x64 (does that exist?) or (insert equivalent Vista here) then the installer you are looking for is the 'AMD64' one.' What do you think? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 09:52 Message: Logged In: YES user_id=21627 Originator: NO I don't see a need to change the page. It says clearly that the ia64 binary is for "Itanium". If you thought that you had an Itanium processor, there is not much we could do for you. I refuse to call the architecture or the binary "EM64T", "x64", or "x86-64". AMD has invented the architecture, so they get to name it. They originally called it x86-64, but later requested that people call it AMD64, so that's what we do. Notice that Microsoft calls the operating system you are running "XP x64 Edition", not "XP 64". They also offer "XP 64-bit Itanium Edition". So Windows users just have to learn that "64-bit Windows" is not a precise architecture specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 From noreply at sourceforge.net Sat Dec 16 13:19:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 04:19:35 -0800 Subject: [ python-Bugs-1616109 ] IA64/AMD64/x64 confusion Message-ID: Bugs item #1616109, was opened at 2006-12-14 21:51 Message generated for change (Comment added) made by dreamcatcher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&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: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. ---------------------------------------------------------------------- >Comment By: Sidnei da Silva (dreamcatcher) Date: 2006-12-16 10:19 Message: Logged In: YES user_id=438768 Originator: YES Doesn't sound like you read my suggestion: """ If you are running XP x64, 2003 x64 (does that exist?) or (insert equivalent Vista here) then the installer you are looking for is the 'AMD64' one. """ There's no mention of Intel there. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 10:09 Message: Logged In: YES user_id=21627 Originator: NO I would like to avoid adding more text. It is already too much text. Also, I outright refuse to use any of the official Intel terminology on an official webpage (and, as you say, EM64T is not the current name that Intel gives this anymore; the brain washing goes on as they called "Intel 64" now, just as if they invented it). ---------------------------------------------------------------------- Comment By: Sidnei da Silva (dreamcatcher) Date: 2006-12-16 09:40 Message: Logged In: YES user_id=438768 Originator: YES I understand that calling it AMD64 is the 'correct' thing. However the end user will say 'but I have an Intel processor, not AMD'. I'm not asking for a rename, just for a note on the download page. You shouldn't expect the users downloading this to know the difference between 'Itanium' vs 'AMD64' vs 'EM64T'. They probably, though, know the difference between 'XP Itanium Edition' and 'XP x64 Edition'. Since the 'AMD64' installer will work on 'XP x64' no matter if the processor is AMD64 or EM64T, I think the page should at least say something like: 'If you are running XP x64, 2003 x64 (does that exist?) or (insert equivalent Vista here) then the installer you are looking for is the 'AMD64' one.' What do you think? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 06:52 Message: Logged In: YES user_id=21627 Originator: NO I don't see a need to change the page. It says clearly that the ia64 binary is for "Itanium". If you thought that you had an Itanium processor, there is not much we could do for you. I refuse to call the architecture or the binary "EM64T", "x64", or "x86-64". AMD has invented the architecture, so they get to name it. They originally called it x86-64, but later requested that people call it AMD64, so that's what we do. Notice that Microsoft calls the operating system you are running "XP x64 Edition", not "XP 64". They also offer "XP 64-bit Itanium Edition". So Windows users just have to learn that "64-bit Windows" is not a precise architecture specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 From noreply at sourceforge.net Sat Dec 16 14:32:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 05:32:34 -0800 Subject: [ python-Bugs-1616109 ] IA64/AMD64/x64 confusion Message-ID: Bugs item #1616109, was opened at 2006-12-15 00:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&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: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Sidnei da Silva (dreamcatcher) Assigned to: Nobody/Anonymous (nobody) Summary: IA64/AMD64/x64 confusion Initial Comment: I've recently got a Intel EM64T-enabled machine, which until recently I didn't realise was actually 64-bit. Now I'm running Windows XP 64 Professional, and thought about downloading the 64-bit installer. Coming to the Python 2.5 download page, there are two options, 'IA64' and 'AMD64'. You would have thought that, since this is an Intel box, the 'IA64' seems like the obvious choice, but that installer does not work. After starting it, a dialog pops up with the message: """ This installation package is not supported by this processor type. Please contact your vendor. """ So I went and downloaded the AMD64 installer. And to my surprise, it does work! To make it worse, Intel seems to have renamed 'EM64T' to 'Intel 64 Architecture'. http://en.wikipedia.org/wiki/EM64T I believe that an explanation should be added to the download page clarifying that EM64T is actually Intel's implementation of AMD64, and that it's not compatible with the 'IA64' installer. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 14:32 Message: Logged In: YES user_id=21627 Originator: NO Ok, I added a mentioning of the target operating system to the website. ---------------------------------------------------------------------- Comment By: Sidnei da Silva (dreamcatcher) Date: 2006-12-16 13:19 Message: Logged In: YES user_id=438768 Originator: YES Doesn't sound like you read my suggestion: """ If you are running XP x64, 2003 x64 (does that exist?) or (insert equivalent Vista here) then the installer you are looking for is the 'AMD64' one. """ There's no mention of Intel there. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 13:09 Message: Logged In: YES user_id=21627 Originator: NO I would like to avoid adding more text. It is already too much text. Also, I outright refuse to use any of the official Intel terminology on an official webpage (and, as you say, EM64T is not the current name that Intel gives this anymore; the brain washing goes on as they called "Intel 64" now, just as if they invented it). ---------------------------------------------------------------------- Comment By: Sidnei da Silva (dreamcatcher) Date: 2006-12-16 12:40 Message: Logged In: YES user_id=438768 Originator: YES I understand that calling it AMD64 is the 'correct' thing. However the end user will say 'but I have an Intel processor, not AMD'. I'm not asking for a rename, just for a note on the download page. You shouldn't expect the users downloading this to know the difference between 'Itanium' vs 'AMD64' vs 'EM64T'. They probably, though, know the difference between 'XP Itanium Edition' and 'XP x64 Edition'. Since the 'AMD64' installer will work on 'XP x64' no matter if the processor is AMD64 or EM64T, I think the page should at least say something like: 'If you are running XP x64, 2003 x64 (does that exist?) or (insert equivalent Vista here) then the installer you are looking for is the 'AMD64' one.' What do you think? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 09:52 Message: Logged In: YES user_id=21627 Originator: NO I don't see a need to change the page. It says clearly that the ia64 binary is for "Itanium". If you thought that you had an Itanium processor, there is not much we could do for you. I refuse to call the architecture or the binary "EM64T", "x64", or "x86-64". AMD has invented the architecture, so they get to name it. They originally called it x86-64, but later requested that people call it AMD64, so that's what we do. Notice that Microsoft calls the operating system you are running "XP x64 Edition", not "XP 64". They also offer "XP 64-bit Itanium Edition". So Windows users just have to learn that "64-bit Windows" is not a precise architecture specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616109&group_id=5470 From noreply at sourceforge.net Sat Dec 16 20:03:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 11:03:24 -0800 Subject: [ python-Bugs-1616422 ] Wrong pathname value in logging output Message-ID: Bugs item #1616422, was opened at 2006-12-15 15:30 Message generated for change (Comment added) made by simleo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&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: Python Library Group: Python 2.4 >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Tekkaman (simleo) Assigned to: Vinay Sajip (vsajip) Summary: Wrong pathname value in logging output Initial Comment: When trying to log caller pathname information, instead of the actual caller's name I get the full name of the logging module source file: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') /usr/lib/python2.4/logging/__init__.py >>> I've been discussing this on comp.lang.python and the suspect arised that this has something to do with a symlink in the path leading to the module source file (I have a lib -> lib64 symlink on my system). To verify this I copied the entire logging directory into my home dir and retried. This is what I got: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') >>> Additional info: Python Version: 2.4.3 OS: Gentoo Linux 2.6.17-r8 CPU: AMD Turion(tm) 64 Mobile Technology sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/dbus', '/usr/lib64/python2.4/site-packages/gtk-2.0'] ---------------------------------------------------------------------- >Comment By: Tekkaman (simleo) Date: 2006-12-16 20:03 Message: Logged In: YES user_id=1669352 Originator: YES I don't get , I get "/usr/lib/python2.4/logging/__init__.py". I got (correct behaviour) only after copying the entire logging directory in the same place where I started the interpreter. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 18:20 Message: Logged In: YES user_id=308438 Originator: NO Sorry, why is this wrong? You are making the logging call from an interactive prompt - so you would expect to get the pathname of , would you not? I get the same output on Windows where the only logging module is the one which is part of the standard Python installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470 From noreply at sourceforge.net Sat Dec 16 20:09:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 11:09:10 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: David Watson (baikie) Date: 2006-12-16 19:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 14:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 13:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 21:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 20:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Sat Dec 16 22:36:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 13:36:32 -0800 Subject: [ python-Bugs-1617161 ] Instance methods compare equal when their self's are equal Message-ID: Bugs item #1617161, was opened at 2006-12-16 22:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1617161&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Niessink (fniessink) Assigned to: Nobody/Anonymous (nobody) Summary: Instance methods compare equal when their self's are equal Initial Comment: Python 2.5 was changed so that instance methods compare equal when their im_self attributes compare equal. Here's a link to that change: http://svn.python.org/view?rev=46739&view=rev This is a problem if we want to distinguish between methods of instances that compare equal, for example when methods can be registered as callbacks (see attached example). It seems unlogical to me that whether or not the instance methods of two different instances are equal or not depends on the equality of the instance. Thanks, Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1617161&group_id=5470 From noreply at sourceforge.net Sat Dec 16 23:38:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 14:38:19 -0800 Subject: [ python-Bugs-1616422 ] Wrong pathname value in logging output Message-ID: Bugs item #1616422, was opened at 2006-12-15 14:30 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&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: Python Library Group: Python 2.4 >Status: Pending >Resolution: None Priority: 5 Private: No Submitted By: Tekkaman (simleo) Assigned to: Vinay Sajip (vsajip) Summary: Wrong pathname value in logging output Initial Comment: When trying to log caller pathname information, instead of the actual caller's name I get the full name of the logging module source file: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') /usr/lib/python2.4/logging/__init__.py >>> I've been discussing this on comp.lang.python and the suspect arised that this has something to do with a symlink in the path leading to the module source file (I have a lib -> lib64 symlink on my system). To verify this I copied the entire logging directory into my home dir and retried. This is what I got: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') >>> Additional info: Python Version: 2.4.3 OS: Gentoo Linux 2.6.17-r8 CPU: AMD Turion(tm) 64 Mobile Technology sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/dbus', '/usr/lib64/python2.4/site-packages/gtk-2.0'] ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-16 22:38 Message: Logged In: YES user_id=308438 Originator: NO Right, but I'm not sure the problem's in logging. Logging uses the filename built into the compiled code objects as it walks up the stack, looking for a filename which is not the source file of the logging package. Try deleting all your .pyc and .pyo files (including the ones in the logging package) and see if there is a change in behaviour; what value does logging._srcFile have? Does it accord with what you would expect? The symlink could mean that the compiled filename in the .pyc/.pyo is out of date. ---------------------------------------------------------------------- Comment By: Tekkaman (simleo) Date: 2006-12-16 19:03 Message: Logged In: YES user_id=1669352 Originator: YES I don't get , I get "/usr/lib/python2.4/logging/__init__.py". I got (correct behaviour) only after copying the entire logging directory in the same place where I started the interpreter. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 17:20 Message: Logged In: YES user_id=308438 Originator: NO Sorry, why is this wrong? You are making the logging call from an interactive prompt - so you would expect to get the pathname of , would you not? I get the same output on Windows where the only logging module is the one which is part of the standard Python installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470 From noreply at sourceforge.net Sun Dec 17 00:07:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Dec 2006 15:07:01 -0800 Subject: [ python-Bugs-1617161 ] Instance methods compare equal when their self's are equal Message-ID: Bugs item #1617161, was opened at 2006-12-16 22:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1617161&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Niessink (fniessink) >Assigned to: Armin Rigo (arigo) Summary: Instance methods compare equal when their self's are equal Initial Comment: Python 2.5 was changed so that instance methods compare equal when their im_self attributes compare equal. Here's a link to that change: http://svn.python.org/view?rev=46739&view=rev This is a problem if we want to distinguish between methods of instances that compare equal, for example when methods can be registered as callbacks (see attached example). It seems unlogical to me that whether or not the instance methods of two different instances are equal or not depends on the equality of the instance. Thanks, Frank ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-17 00:07 Message: Logged In: YES user_id=21627 Originator: NO Armin, can you please comment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1617161&group_id=5470 From noreply at sourceforge.net Sun Dec 17 13:19:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Dec 2006 04:19:51 -0800 Subject: [ python-Bugs-1617161 ] Instance methods compare equal when their self's are equal Message-ID: Bugs item #1617161, was opened at 2006-12-16 21:36 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1617161&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Niessink (fniessink) Assigned to: Armin Rigo (arigo) >Summary: Instance methods compare equal when their self's are equal Initial Comment: Python 2.5 was changed so that instance methods compare equal when their im_self attributes compare equal. Here's a link to that change: http://svn.python.org/view?rev=46739&view=rev This is a problem if we want to distinguish between methods of instances that compare equal, for example when methods can be registered as callbacks (see attached example). It seems unlogical to me that whether or not the instance methods of two different instances are equal or not depends on the equality of the instance. Thanks, Frank ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-12-17 12:19 Message: Logged In: YES user_id=4771 Originator: NO I see. Indeed, in the callback situation the 2.5 change is not very good. On the other hand, I have a (possibly more obscure) case where the new equality makes more sense. Note also that the change was meant to unify the behavior of built-in and user method objects; e.g. if you use callbacks as dict keys, then already in previous Python versions it was impossible to use say 'mylist.append' as a callback. Moreover, the hash of user methods was strangely based on the hash of the object itself already, which made dict key collisions likely. All in all I think that this part was an accident and never designed; I won't pronounce myself and suggest that python-dev should decide which of the two behaviors is realy "expected". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-16 23:07 Message: Logged In: YES user_id=21627 Originator: NO Armin, can you please comment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1617161&group_id=5470 From noreply at sourceforge.net Mon Dec 18 05:45:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 17 Dec 2006 20:45:26 -0800 Subject: [ python-Feature Requests-1504947 ] There should be a Python build using Visual Studio 2005 Message-ID: Feature Requests item #1504947, was opened at 2006-06-12 19:08 Message generated for change (Comment added) made by dobesv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1504947&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 Private: No Submitted By: Vincent Manis (vmanis) Assigned to: Nobody/Anonymous (nobody) Summary: There should be a Python build using Visual Studio 2005 Initial Comment: This report is a follow-on from Bug# 1498051, which complained that Distutils doesn't recognize Visual Studio 2005. That bug was closed with a statement that extensions should be built with the same version of the MS compiler that built the Python system. Given that Visual Studio 2003 is no longer available as a commercial product from Microsoft, many people (myself included) must use Visual Studio 2005. Therefore, I am requesting that a separate `batteries included' Windows installer be provided where everything has been built with VS2005. ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2006-12-18 04:45 Message: Logged In: YES user_id=400635 Originator: NO You don't have to provide several different builds - only the 2005 build is needed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-13 17:18 Message: Logged In: YES user_id=21627 Recategorizing as a feature request. I'm personally not willing to produce several different x86 windows packages. However, sources are available, so if somebody things this should be provided, they are certainly free to provide it themselves. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1504947&group_id=5470 From noreply at sourceforge.net Mon Dec 18 09:43:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 00:43:33 -0800 Subject: [ python-Feature Requests-1504947 ] There should be a Python build using Visual Studio 2005 Message-ID: Feature Requests item #1504947, was opened at 2006-06-12 21:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1504947&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 Private: No Submitted By: Vincent Manis (vmanis) Assigned to: Nobody/Anonymous (nobody) Summary: There should be a Python build using Visual Studio 2005 Initial Comment: This report is a follow-on from Bug# 1498051, which complained that Distutils doesn't recognize Visual Studio 2005. That bug was closed with a statement that extensions should be built with the same version of the MS compiler that built the Python system. Given that Visual Studio 2003 is no longer available as a commercial product from Microsoft, many people (myself included) must use Visual Studio 2005. Therefore, I am requesting that a separate `batteries included' Windows installer be provided where everything has been built with VS2005. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-18 09:43 Message: Logged In: YES user_id=21627 Originator: NO It is not true that only the 2005 build is needed. Many people specifically requested that Python 2.5 is built with VS 2003, so they need the (current) 2003 build. ---------------------------------------------------------------------- Comment By: Dobes V (dobesv) Date: 2006-12-18 05:45 Message: Logged In: YES user_id=400635 Originator: NO You don't have to provide several different builds - only the 2005 build is needed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-13 19:18 Message: Logged In: YES user_id=21627 Recategorizing as a feature request. I'm personally not willing to produce several different x86 windows packages. However, sources are available, so if somebody things this should be provided, they are certainly free to provide it themselves. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1504947&group_id=5470 From noreply at sourceforge.net Mon Dec 18 10:29:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 01:29:44 -0800 Subject: [ python-Bugs-1616422 ] Wrong pathname value in logging output Message-ID: Bugs item #1616422, was opened at 2006-12-15 15:30 Message generated for change (Comment added) made by simleo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&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: Python Library Group: Python 2.4 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tekkaman (simleo) Assigned to: Vinay Sajip (vsajip) Summary: Wrong pathname value in logging output Initial Comment: When trying to log caller pathname information, instead of the actual caller's name I get the full name of the logging module source file: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') /usr/lib/python2.4/logging/__init__.py >>> I've been discussing this on comp.lang.python and the suspect arised that this has something to do with a symlink in the path leading to the module source file (I have a lib -> lib64 symlink on my system). To verify this I copied the entire logging directory into my home dir and retried. This is what I got: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') >>> Additional info: Python Version: 2.4.3 OS: Gentoo Linux 2.6.17-r8 CPU: AMD Turion(tm) 64 Mobile Technology sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/dbus', '/usr/lib64/python2.4/site-packages/gtk-2.0'] ---------------------------------------------------------------------- >Comment By: Tekkaman (simleo) Date: 2006-12-18 10:29 Message: Logged In: YES user_id=1669352 Originator: YES Deleting all .pyc and .pyo files solved the problem. Now I get the correct behaviour. However, this is not an option for a machine on which one does not have root privileges. Can the code be changed in such a way that it's not fooled by outdated .pyc and .pyo files? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-16 23:38 Message: Logged In: YES user_id=308438 Originator: NO Right, but I'm not sure the problem's in logging. Logging uses the filename built into the compiled code objects as it walks up the stack, looking for a filename which is not the source file of the logging package. Try deleting all your .pyc and .pyo files (including the ones in the logging package) and see if there is a change in behaviour; what value does logging._srcFile have? Does it accord with what you would expect? The symlink could mean that the compiled filename in the .pyc/.pyo is out of date. ---------------------------------------------------------------------- Comment By: Tekkaman (simleo) Date: 2006-12-16 20:03 Message: Logged In: YES user_id=1669352 Originator: YES I don't get , I get "/usr/lib/python2.4/logging/__init__.py". I got (correct behaviour) only after copying the entire logging directory in the same place where I started the interpreter. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 18:20 Message: Logged In: YES user_id=308438 Originator: NO Sorry, why is this wrong? You are making the logging call from an interactive prompt - so you would expect to get the pathname of , would you not? I get the same output on Windows where the only logging module is the one which is part of the standard Python installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470 From noreply at sourceforge.net Mon Dec 18 10:54:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 01:54:05 -0800 Subject: [ python-Bugs-1616422 ] Wrong pathname value in logging output Message-ID: Bugs item #1616422, was opened at 2006-12-15 14:30 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&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: Python Library Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Tekkaman (simleo) Assigned to: Vinay Sajip (vsajip) Summary: Wrong pathname value in logging output Initial Comment: When trying to log caller pathname information, instead of the actual caller's name I get the full name of the logging module source file: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') /usr/lib/python2.4/logging/__init__.py >>> I've been discussing this on comp.lang.python and the suspect arised that this has something to do with a symlink in the path leading to the module source file (I have a lib -> lib64 symlink on my system). To verify this I copied the entire logging directory into my home dir and retried. This is what I got: >>> import logging >>> logging.basicConfig(format='%(pathname)s') >>> logging.getLogger('').critical('foo') >>> Additional info: Python Version: 2.4.3 OS: Gentoo Linux 2.6.17-r8 CPU: AMD Turion(tm) 64 Mobile Technology sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/dbus', '/usr/lib64/python2.4/site-packages/gtk-2.0'] ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-18 09:54 Message: Logged In: YES user_id=308438 Originator: NO Glad the problem's solved. It's not appropriate to change the current behaviour of logging with respect to determining the source file of a module, for a couple of reasons: 1) There are other problems caused by out-of-date .pyo and .pyc files (every use of __file__ is potentially a problem) - which changing logging would not solve. Logging uses __file__ how it is intended to be used. 2) Some systems are shipped with .pyo and .pyc files only - no .py files are available (e.g. frozen systems). ---------------------------------------------------------------------- Comment By: Tekkaman (simleo) Date: 2006-12-18 09:29 Message: Logged In: YES user_id=1669352 Originator: YES Deleting all .pyc and .pyo files solved the problem. Now I get the correct behaviour. However, this is not an option for a machine on which one does not have root privileges. Can the code be changed in such a way that it's not fooled by outdated .pyc and .pyo files? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-16 22:38 Message: Logged In: YES user_id=308438 Originator: NO Right, but I'm not sure the problem's in logging. Logging uses the filename built into the compiled code objects as it walks up the stack, looking for a filename which is not the source file of the logging package. Try deleting all your .pyc and .pyo files (including the ones in the logging package) and see if there is a change in behaviour; what value does logging._srcFile have? Does it accord with what you would expect? The symlink could mean that the compiled filename in the .pyc/.pyo is out of date. ---------------------------------------------------------------------- Comment By: Tekkaman (simleo) Date: 2006-12-16 19:03 Message: Logged In: YES user_id=1669352 Originator: YES I don't get , I get "/usr/lib/python2.4/logging/__init__.py". I got (correct behaviour) only after copying the entire logging directory in the same place where I started the interpreter. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 17:20 Message: Logged In: YES user_id=308438 Originator: NO Sorry, why is this wrong? You are making the logging call from an interactive prompt - so you would expect to get the pathname of , would you not? I get the same output on Windows where the only logging module is the one which is part of the standard Python installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470 From noreply at sourceforge.net Mon Dec 18 10:57:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 01:57:09 -0800 Subject: [ python-Bugs-1465643 ] test_logging hangs on cygwin Message-ID: Bugs item #1465643, was opened at 2006-04-06 10:44 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&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: Python Library Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on cygwin Initial Comment: Python 2.5a1, CYGWIN make test test_logging hangs ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-18 09:57 Message: Logged In: YES user_id=308438 Originator: NO Is this still a problem, now that 2.5 is out? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&group_id=5470 From noreply at sourceforge.net Mon Dec 18 11:12:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 02:12:10 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 06:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-18 11:12 Message: Logged In: YES user_id=21627 Originator: NO I believe this is a local configuration error, and possibly a C library error. I'll attach two programs: g.c does what I believe gpsd does, and c.py does what I believe spGps.py does. This works fine on my system after I change localhost to be ::1 in /etc/hosts, even though g.c only listens on IPv4 interfaces. On my system, it "works" because libc (getaddrinfo) then goes to DNS, and my DNS server has an entry for localhost. If C programs work on the machine, it may be because they use gethostbyname, not getaddrinfo. Closing as "works for me". File Added: g.c ---------------------------------------------------------------------- Comment By: Robert J. Berger (rjbsourceforge) Date: 2006-12-03 21:15 Message: Logged In: YES user_id=29744 Originator: NO I will try to get a simple example that reproduces it. Unfortunately I don't have access to the system that was doing it today. I will try to get something in the bug report in the next day or so. But basically if /etc/hosts had localhost defined as ::1 the connect method failded, when I set localhost to 127.0.0.1 the connect worked. Other non-python (c++) processes were able to access the socket when localhost was set to ::1 This was on Fedora Core 6 with the latest patches at that time. ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-12-01 23:18 Message: Logged In: YES user_id=3060 Originator: YES >Are you sure this isn't a local misconfiguration? I'm not. I didn't see it happen. I suggest you email Mr. Berger and ask him. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 22:10 Message: Logged In: YES user_id=366566 Originator: NO This seems to work fine for me: >>> s = socket.socket(socket.AF_INET6) >>> s.bind(('ip6-localhost', 8091)) >>> s.getsockname() ('::1', 8091, 0, 0) >>> exarkun at charm:~$ grep ip6-localhost /etc/hosts ::1 ip6-localhost ip6-loopback exarkun at charm:~$ Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't listening on ::1, only 127.1? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-29 22:35 Message: Logged In: YES user_id=3060 Originator: YES host is 'localhost' port is 2947 What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 22:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 07:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Mon Dec 18 11:12:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 02:12:58 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 06:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&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: Python Library Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-18 11:12 Message: Logged In: YES user_id=21627 Originator: NO File Added: c.py ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-18 11:12 Message: Logged In: YES user_id=21627 Originator: NO I believe this is a local configuration error, and possibly a C library error. I'll attach two programs: g.c does what I believe gpsd does, and c.py does what I believe spGps.py does. This works fine on my system after I change localhost to be ::1 in /etc/hosts, even though g.c only listens on IPv4 interfaces. On my system, it "works" because libc (getaddrinfo) then goes to DNS, and my DNS server has an entry for localhost. If C programs work on the machine, it may be because they use gethostbyname, not getaddrinfo. Closing as "works for me". File Added: g.c ---------------------------------------------------------------------- Comment By: Robert J. Berger (rjbsourceforge) Date: 2006-12-03 21:15 Message: Logged In: YES user_id=29744 Originator: NO I will try to get a simple example that reproduces it. Unfortunately I don't have access to the system that was doing it today. I will try to get something in the bug report in the next day or so. But basically if /etc/hosts had localhost defined as ::1 the connect method failded, when I set localhost to 127.0.0.1 the connect worked. Other non-python (c++) processes were able to access the socket when localhost was set to ::1 This was on Fedora Core 6 with the latest patches at that time. ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-12-01 23:18 Message: Logged In: YES user_id=3060 Originator: YES >Are you sure this isn't a local misconfiguration? I'm not. I didn't see it happen. I suggest you email Mr. Berger and ask him. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-12-01 22:10 Message: Logged In: YES user_id=366566 Originator: NO This seems to work fine for me: >>> s = socket.socket(socket.AF_INET6) >>> s.bind(('ip6-localhost', 8091)) >>> s.getsockname() ('::1', 8091, 0, 0) >>> exarkun at charm:~$ grep ip6-localhost /etc/hosts ::1 ip6-localhost ip6-loopback exarkun at charm:~$ Are you sure this isn't a local misconfiguration? Perhaps gpsd isn't listening on ::1, only 127.1? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-29 22:35 Message: Logged In: YES user_id=3060 Originator: YES host is 'localhost' port is 2947 What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 22:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 07:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Mon Dec 18 15:39:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 06:39:35 -0800 Subject: [ python-Bugs-1618083 ] missing word in "sqlite3-Module-Contents"-documentation? Message-ID: Bugs item #1618083, was opened at 2006-12-18 15:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618083&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: 5 Private: No Submitted By: lgvienna (lgvienna) Assigned to: Nobody/Anonymous (nobody) Summary: missing word in "sqlite3-Module-Contents"-documentation? Initial Comment: http://docs.python.org/lib/sqlite3-Module-Contents.html "complete_statement(sql) Returns True if the string sql one or more complete SQL statements terminated by semicolons." is there something like "contains" missing? hope this helps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618083&group_id=5470 From noreply at sourceforge.net Mon Dec 18 17:01:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 08:01:32 -0800 Subject: [ python-Bugs-1465643 ] test_logging hangs on cygwin Message-ID: Bugs item #1465643, was opened at 2006-04-06 13:44 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&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: Python Library Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on cygwin Initial Comment: Python 2.5a1, CYGWIN make test test_logging hangs ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2006-12-18 18:01 Message: Logged In: YES user_id=358087 Originator: YES I have no idea, move to Linux/Mac environment. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-18 11:57 Message: Logged In: YES user_id=308438 Originator: NO Is this still a problem, now that 2.5 is out? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&group_id=5470 From noreply at sourceforge.net Mon Dec 18 17:02:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 08:02:05 -0800 Subject: [ python-Bugs-1465643 ] test_logging hangs on cygwin Message-ID: Bugs item #1465643, was opened at 2006-04-06 13:44 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&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: Python Library Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging hangs on cygwin Initial Comment: Python 2.5a1, CYGWIN make test test_logging hangs ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2006-12-18 18:02 Message: Logged In: YES user_id=358087 Originator: YES (Should have been "moved to") ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-12-18 18:01 Message: Logged In: YES user_id=358087 Originator: YES I have no idea, move to Linux/Mac environment. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-18 11:57 Message: Logged In: YES user_id=308438 Originator: NO Is this still a problem, now that 2.5 is out? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&group_id=5470 From noreply at sourceforge.net Mon Dec 18 18:13:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 09:13:50 -0800 Subject: [ python-Bugs-1618083 ] missing word in "sqlite3-Module-Contents"-documentation? Message-ID: Bugs item #1618083, was opened at 2006-12-18 09:39 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618083&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: lgvienna (lgvienna) >Assigned to: A.M. Kuchling (akuchling) Summary: missing word in "sqlite3-Module-Contents"-documentation? Initial Comment: http://docs.python.org/lib/sqlite3-Module-Contents.html "complete_statement(sql) Returns True if the string sql one or more complete SQL statements terminated by semicolons." is there something like "contains" missing? hope this helps. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 12:13 Message: Logged In: YES user_id=11375 Originator: NO Thanks for pointing this out! Fixed in rev. 53048 on the trunk and rev. 53049 on the 25-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618083&group_id=5470 From noreply at sourceforge.net Mon Dec 18 18:26:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 09:26:57 -0800 Subject: [ python-Bugs-1566280 ] Logging problem on Windows XP Message-ID: Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. L?wis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-18 18:26 Message: Logged In: YES user_id=21627 Originator: NO I cannot reproduce the crash with the example given, neither with the released binaries, nor with any of the trunk or release25-maint subversion branches. Therefore, I declare that this report is only about the ValueError; if anybody has a way to provoke a crash in a reproducable way, please submit it as a separate report, along with precise instructions on how to provoke the crash. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 19:58 Message: Logged In: YES user_id=21627 Originator: NO eloff: It may be that there are different problems that all show the symptom; *this* problem reported here can only occur if you are using multiple threads (atleast for the ValueError; haven't looked into the crash at all). Yes, you can run multiple threads, and yes, you can use logging freely. However, you should not let the main thread just "run off". Instead, you should end your main thread with an explicit .join() operation on all threads it has created; those threads themselves should perform explicit .join() operations on all threads they create. That way, you can guarantee orderly shutdown. threading.py tries to do the joining if you don't, but fails (and the approach it uses is inherently error-prone). ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 19:43 Message: Logged In: YES user_id=730918 Originator: NO Thanks Martin, I applied the patch. The problem I was having was the IO Error, sorry for being vague. The part I don't understand is I should not have had other threads running (and definately should not have had the logger being used outside the main thread.) Can the problem occur with just one thread? I was running under the debugger in wing, I don't know if that might cause this problem. Anyway if I find out anything else I'll let you know. If you don't hear from me then everything is working great. ---------------------------------------------------------------------- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 16:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 08:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff ---------------------------------------------------------------------- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 04:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 15:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 05:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? ---------------------------------------------------------------------- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 14:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC0000005: Access violation reading location 0x00000034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 From noreply at sourceforge.net Mon Dec 18 18:30:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 09:30:30 -0800 Subject: [ python-Bugs-1616726 ] Vague description of generator close() method Message-ID: Bugs item #1616726, was opened at 2006-12-15 16:09 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616726&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: Lenard Lindstrom (kermode) >Assigned to: A.M. Kuchling (akuchling) Summary: Vague description of generator close() method Initial Comment: In section 7 of "What's New in Python 2.5" the subsection on the close() generator method states: close() raises a new GeneratorExit exception inside the generator to terminate the iteration. On receiving this exception, the generator's code must either raise GeneratorExit or StopIteration; catching the exception and doing anything else is illegal and will trigger a RuntimeError. This suggests that if a generator raises a new exception that is neither a GeneratorExit nor StopIteration a RuntimeError is raised. But this is not the case according to Part 4 of PEP 342's "Specification Summary": If the generator raises any other exception, it is propagated to the caller. The Python 2.5 interpreter is consistent with PEP 342: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> def raise_wrong_exception(): ... try: ... yield 1 ... yield 2 ... except GeneratorExit: ... raise TypeError("Where is the RuntimeError?") ... >>> i=raise_wrong_exception() >>> i.next() 1 >>> i.close() Traceback (most recent call last): File "", line 1, in File "", line 6, in raise_wrong_exception TypeError: Where is the RuntimeError? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 12:30 Message: Logged In: YES user_id=11375 Originator: NO You're right; thanks for pointing out the error. Corrected in rev. 53051. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616726&group_id=5470 From noreply at sourceforge.net Mon Dec 18 18:43:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 09:43:49 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 12:43 Message: Logged In: YES user_id=11375 Originator: NO Eep, correct; changing the key IDs would be a big problem for existing code. We could say 'discard all keys' after doing lock() or unlock(), but this is an API change that means the fix couldn't be backported to 2.5-maint. We could make generating the ToC more complicated, preserving key IDs when possible; that may not be too difficult, though the code might be messy. Maybe it's best to just catch this error condition: save the size of the mailbox, updating it in _append_message(), and then make .flush() raise an exception if the mailbox size has unexpectedly changed. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-16 14:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 09:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Tue Dec 19 00:12:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Dec 2006 15:12:41 -0800 Subject: [ python-Bugs-1618455 ] HMAC can get a 6x performance increase easily Message-ID: Bugs item #1618455, was opened at 2006-12-18 18:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618455&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Maurer (bmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: HMAC can get a 6x performance increase easily Initial Comment: The attached patch increases the performance of HMAC by a factor of 6. It does so by avoiding useing join/map in the strxor and using a lookup table. It would be faster just to do xor at the string level, but it's not clear that can be done without help from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618455&group_id=5470 From noreply at sourceforge.net Tue Dec 19 11:08:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 02:08:53 -0800 Subject: [ python-Feature Requests-1618676 ] Improve list comprehensions to Language Integrated Query? Message-ID: Feature Requests item #1618676, was opened at 2006-12-19 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&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: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: Improve list comprehensions to Language Integrated Query? Initial Comment: Hi, A feature idea (shall put to mailing list discussion sometime), is to extend list comprehensions to many uses of SQL or XQuery unnecessary. The benefit of language integration over passing SQL/XQuery strings to external libraries would be making code agnostic to the source of the data: in-memory tables and trees could be queried just like a relational DB or XML. An "order by" could be more efficient than sorted(f(x) for x in y). Of course list comprehensions do much of the C#-style LINQ already, but they can't (easily) do joins or "select x from a, y from b" type queries, or return XML a la XQuery. On the library side, DBAPI helps make code independent of any particular database, and sqlite in 2.5 means in-memory tables (lists of tuples) aren't really necessary. If worthwhile, implementation would probably be best suited to PyPy. C# Example from http://en.wikipedia.org/wiki/Language_Integrated_Query var q = from o in db.Orders, c in db.Customers where o.Quality == "200" && (o.CustomerID == c.CustomerID) select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&group_id=5470 From noreply at sourceforge.net Tue Dec 19 11:10:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 02:10:31 -0800 Subject: [ python-Feature Requests-1618676 ] Promote list comprehensions to Language Integrated Query? Message-ID: Feature Requests item #1618676, was opened at 2006-12-19 12:08 Message generated for change (Settings changed) made by jettlogic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&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: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) >Summary: Promote list comprehensions to Language Integrated Query? Initial Comment: Hi, A feature idea (shall put to mailing list discussion sometime), is to extend list comprehensions to many uses of SQL or XQuery unnecessary. The benefit of language integration over passing SQL/XQuery strings to external libraries would be making code agnostic to the source of the data: in-memory tables and trees could be queried just like a relational DB or XML. An "order by" could be more efficient than sorted(f(x) for x in y). Of course list comprehensions do much of the C#-style LINQ already, but they can't (easily) do joins or "select x from a, y from b" type queries, or return XML a la XQuery. On the library side, DBAPI helps make code independent of any particular database, and sqlite in 2.5 means in-memory tables (lists of tuples) aren't really necessary. If worthwhile, implementation would probably be best suited to PyPy. C# Example from http://en.wikipedia.org/wiki/Language_Integrated_Query var q = from o in db.Orders, c in db.Customers where o.Quality == "200" && (o.CustomerID == c.CustomerID) select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:16:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:16:25 -0800 Subject: [ python-Bugs-1618455 ] HMAC can get a 6x performance increase easily Message-ID: Bugs item #1618455, was opened at 2006-12-18 18:12 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618455&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: Python Library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Ben Maurer (bmaurer) >Assigned to: A.M. Kuchling (akuchling) Summary: HMAC can get a 6x performance increase easily Initial Comment: The attached patch increases the performance of HMAC by a factor of 6. It does so by avoiding useing join/map in the strxor and using a lookup table. It would be faster just to do xor at the string level, but it's not clear that can be done without help from C. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 09:16 Message: Logged In: YES user_id=11375 Originator: NO Thanks for your patch; I've modified it to remove _strxor() completely and applied the change as rev. 53065. When I tried a trivial benchmark, the speed improvement wasn't anywhere near 6X, and was more like 7%. The patch is still worth applying because it also simplifies the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618455&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:29:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:29:47 -0800 Subject: [ python-Bugs-1613651 ] recv_into not documented Message-ID: Bugs item #1613651, was opened at 2006-12-11 21:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613651&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: Eric Huss (ehuss) >Assigned to: A.M. Kuchling (akuchling) Summary: recv_into not documented Initial Comment: The recv_into socket method does not appear to be documented in the Library Reference. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 09:29 Message: Logged In: YES user_id=11375 Originator: NO I've added descriptions for these two methods to the trunk in rev. 53066, and will backport to 25-maint once I've verified that my markup is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1613651&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:32:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:32:52 -0800 Subject: [ python-Bugs-1603424 ] subprocess.py (py2.5) wrongly claims py2.2 compatibility Message-ID: Bugs item #1603424, was opened at 2006-11-26 20:07 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603424&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Wegener (twegener) >Assigned to: Peter ?strand (astrand) Summary: subprocess.py (py2.5) wrongly claims py2.2 compatibility Initial Comment: >From the comments in subprocess.py (py2.5): # This module should remain compatible with Python 2.2, see PEP 291. However, using it from Python 2.2 gives: NameError: global name 'set' is not defined (set built-in used on line 1005) The subprocess.py in py2.4 was 2.2 compatible. Either the compatibility comment should be removed/amended or compatibility fixed. ---------------------------------------------------------------------- Comment By: Robert Carr (racarr) Date: 2006-12-05 10:10 Message: Logged In: YES user_id=1649655 Originator: NO Index: subprocess.py =================================================================== --- subprocess.py (revision 52918) +++ subprocess.py (working copy) @@ -1004,8 +1004,8 @@ # Close pipe fds. Make sure we don't close the same # fd more than once, or standard fds. - for fd in set((p2cread, c2pwrite, errwrite))-set((0,1,2)): - if fd: os.close(fd) + for fd in (p2cread,c2pwrite,errwrite): + if fd not in (0,1,2): os.close(fd) # Close all other fds, if asked for if close_fds: Fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603424&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:32:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:32:52 -0800 Subject: [ python-Bugs-1604851 ] subprocess.Popen closes fds for sys.stdout or sys.stderr Message-ID: Bugs item #1604851, was opened at 2006-11-28 17:17 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604851&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nishkar Grover (ngrover) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen closes fds for sys.stdout or sys.stderr Initial Comment: I found a problem in subprocess.Popen's _execute_child() method for POSIX, where the child process will close the fds for sys.stdout and/or sys.stderr if I use those as stdout and/or stderr when creating a subprocess.Popen object. Here's what I saw by default when using the 2.4.4 version of Python... % ./python Python 2.4.4 (#1, Nov 28 2006, 14:08:29) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import sys, subprocess >>> uname = subprocess.Popen('uname -a', shell=True, stdout=sys.stdout) >>> uname: write error: Bad file descriptor >>> Then, I updated subprocess.py and made the following changes... % diff subprocess.py subprocess.py.orig 924c924 < # fd more than once and don't close sys.stdout or sys.stderr. --- > # fd more than once. 927c927 < if c2pwrite and c2pwrite not in (p2cread, sys.stdout.fileno(), sys.stderr.fileno()): --- > if c2pwrite and c2pwrite not in (p2cread,): 929c929 < if errwrite and errwrite not in (p2cread, c2pwrite, sys.stdout.fileno(), sys.stderr.fileno()): --- > if errwrite and errwrite not in (p2cread, c2pwrite): After that, I saw the following... % ./python Python 2.4.4 (#1, Nov 28 2006, 14:08:29) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import sys, subprocess >>> uname = subprocess.Popen('uname -a', shell=True, stdout=sys.stdout) >>> Linux schnauzer 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006 i686 i686 i386 GNU/Linux >>> I'm attaching the modified version of subprocess.py. Please consider adding this fix to future versions of Python. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604851&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:32:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:32:52 -0800 Subject: [ python-Bugs-1615376 ] subprocess doesn\'t handle SIGPIPE Message-ID: Bugs item #1615376, was opened at 2006-12-13 19:21 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615376&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) >Assigned to: Peter ?strand (astrand) >Summary: subprocess doesn\'t handle SIGPIPE Initial Comment: subprocess keeps other side of child pipe open, making use of SIGPIPE to terminate writers in a pipeline not possible. This is probably a matter of documentation or providing a method to link up processes, as the parent end of the pipe must remain open until it is connected to the next process in the pipeline. An option to enable sigpipe in child would be nice. Simple example attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615376&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:50:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:50:14 -0800 Subject: [ python-Bugs-1597798 ] Modules/readline.c fails to compile on AIX 4.2 Message-ID: Bugs item #1597798, was opened at 2006-11-16 10:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597798&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 Private: No Submitted By: Mike Kent (mikekent) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/readline.c fails to compile on AIX 4.2 Initial Comment: Python 2.5 Modules/readline.c line 681 is: return completion_matches(text, *on_completion); on_completion is a function declared as: static char *on_completion(char *text, int state); completion_matches is a macro that expands to: rl_completion_matches((x), ((rl_compentry_func_t *)(y))) SO, the second parameter to completion_matches should be a function pointer (on_completion), not the dereferenced function pointer that is currently passed to it (*on_completion). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 09:50 Message: Logged In: YES user_id=11375 Originator: NO Can you please provide a patch that fixes things? It's difficult for us to provide a patch that will fix the problem on AIX because we don't have access to an AIX machine for testing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597798&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:51:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:51:31 -0800 Subject: [ python-Bugs-1593035 ] readline problem on ia64-unknown-linux-gnu Message-ID: Bugs item #1593035, was opened at 2006-11-08 18:48 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593035&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kate Minola (kate01123) Assigned to: Nobody/Anonymous (nobody) Summary: readline problem on ia64-unknown-linux-gnu Initial Comment: On my ia64-unknown-linux-gnu machine, running python-2.5, if I import the following code (foo.py) and then try to do file name completion, I get a segmentation fault. Specifically, if after importing foo.py, if I type "im" and then [tab], I get a segmentation fault. I built python-2.5 from source using the default values. (All I did was "configure", then "make".) This does NOT happen under python-2.4.4. ----- foo.py ------ try: import rlcompleter,readline except ImportError: print '*** No readline support ***' pass else: readline.set_history_length(1000) # parse and bind all these: rlcmds = ['tab: complete', r'"\M-p": history-search-backward', r'"\M-n": history-search-forward', r'"\C-p": history-search-backward', r'"\C-n": history-search-forward', r'"\e[A": history-search-backward', r'"\e[B": history-search-forward', 'set show-all-if-ambiguous on', ] map(readline.parse_and_bind,rlcmds) ----------------------- %uname -a Linux lepidus 2.4.21-sgi302r24 #1 SMP Fri Oct 22 22:43:12 PDT 2004 ia64 ia64 ia64 GNU/Linux % % ./python --version Python 2.5 % % ./python Python 2.5 (r25:51908, Nov 8 2006, 15:40:13) [GCC 4.1.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo >>> impSegmentation fault (core dumped) % % gdb ./python GNU gdb Red Hat Linux (6.0post-0.20040223.20rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /home/kate/sage/william/Python-2.5/python [Thread debugging using libthread_db enabled] [New Thread 2305843009213881680 (LWP 23166)] Python 2.5 (r25:51908, Nov 8 2006, 15:40:13) [GCC 4.1.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo >>> im Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2305843009213881680 (LWP 23166)] 0x200000000264ae90 in rl_complete_internal () from /usr/lib/libreadline.so.4 (gdb) bt #0 0x200000000264ae90 in rl_complete_internal () from /usr/lib/libreadline.so.4 #1 0x2000000002646d90 in rl_complete () from /usr/lib/libreadline.so.4 #2 0x200000000263bc40 in _rl_dispatch_subseq () from /usr/lib/libreadline.so.4 #3 0x200000000263b780 in _rl_dispatch () from /usr/lib/libreadline.so.4 #4 0x200000000263af90 in readline_internal_char () from /usr/lib/libreadline.so.4 #5 0x0000000000000000 in ?? () (gdb) Kate Minola University of Maryland, College Park ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 09:51 Message: Logged In: YES user_id=11375 Originator: NO I wonder if this crash is related to the function pointer issue described in bug #1597798. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593035&group_id=5470 From noreply at sourceforge.net Tue Dec 19 15:58:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 06:58:56 -0800 Subject: [ python-Bugs-1618455 ] HMAC can get a 6x performance increase easily Message-ID: Bugs item #1618455, was opened at 2006-12-18 18:12 Message generated for change (Comment added) made by bmaurer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618455&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: Python Library Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Ben Maurer (bmaurer) Assigned to: A.M. Kuchling (akuchling) Summary: HMAC can get a 6x performance increase easily Initial Comment: The attached patch increases the performance of HMAC by a factor of 6. It does so by avoiding useing join/map in the strxor and using a lookup table. It would be faster just to do xor at the string level, but it's not clear that can be done without help from C. ---------------------------------------------------------------------- >Comment By: Ben Maurer (bmaurer) Date: 2006-12-19 09:58 Message: Logged In: YES user_id=660878 Originator: YES The performance increase is if you call hmac.new a lot. I did a benchmark on a relatively small amount of cleartext (50 bytes). This was actually something I needed to use. One thing I found -- reusing teh same hmac option helps *ALOT* the hmac docs don't make it clear how much this will help. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 09:16 Message: Logged In: YES user_id=11375 Originator: NO Thanks for your patch; I've modified it to remove _strxor() completely and applied the change as rev. 53065. When I tried a trivial benchmark, the speed improvement wasn't anywhere near 6X, and was more like 7%. The patch is still worth applying because it also simplifies the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1618455&group_id=5470 From noreply at sourceforge.net Tue Dec 19 20:59:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 11:59:08 -0800 Subject: [ python-Bugs-1603150 ] wave module forgets to close file on exception Message-ID: Bugs item #1603150, was opened at 2006-11-26 08:59 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 14:59 Message: Logged In: YES user_id=11375 Originator: NO Try putting the Wave.open() inside the try...finally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 From noreply at sourceforge.net Tue Dec 19 22:14:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 13:14:15 -0800 Subject: [ python-Bugs-1619060 ] bisect on presorted list Message-ID: Bugs item #1619060, was opened at 2006-12-19 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&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: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) Assigned to: Nobody/Anonymous (nobody) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&group_id=5470 From noreply at sourceforge.net Tue Dec 19 22:43:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 13:43:17 -0800 Subject: [ python-Bugs-1619060 ] bisect on presorted list Message-ID: Bugs item #1619060, was opened at 2006-12-19 16:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&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: Extension Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) Assigned to: Nobody/Anonymous (nobody) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-19 16:43 Message: Logged In: YES user_id=80475 Originator: NO I'm -1 on this patch. At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key. In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again. This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern). By including custom sorting in bisect's API we would be diverting users away from better approaches. A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&group_id=5470 From noreply at sourceforge.net Wed Dec 20 00:22:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 15:22:43 -0800 Subject: [ python-Bugs-1619130 ] 64-bit Universal Binary build broken Message-ID: Bugs item #1619130, was opened at 2006-12-19 15:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Treadway (treadway) Assigned to: Jack Jansen (jackjansen) Summary: 64-bit Universal Binary build broken Initial Comment: Hi, I'm running into problem building a 4-way universal binary of python. The following has cropped up on both python2.5 and python2.4.2 The configure goes OK, but the make bombs. [2244]$ ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \ -Wstrict-prototypes -fno-common -fPIC \ -isysroot /Developer/SDKs/MacOSX10.4u.sdk \ -arch ppc -arch i386 -arch ppc64 -arch x86_64" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\ -headerpad_max_install_names -arch ppc -arch i386 \ -arch ppc64 -arch x86_64" . . . [2245]$ make gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from ./Include/Python.h:57In file included from ./Include/Python.h:57, from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." , from ./Modules/python.c:3: ./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out make: *** [Modules/python.o] Error 1 Comenting out the "#error" statement in pyport.h get me a little further befor getting: gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I. -I./Include -DPy_BUILD_CORE -o Python/mactoolboxglue.o Python/mactoolboxglue.c In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, . . . from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20, from ./Include/pymactoolbox.h:10, from Python/mactoolboxglue.c:27: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338: error: 'SIGDIGLEN' undeclared here (not in a function) lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out make: *** [Python/mactoolboxglue.o] Error 1 Seem Carbon doesn't support 64-bits! Is there a solution? trt -- Thomas R. Treadway Computer Scientist Lawrence Livermore Nat'l Lab 7000 East Avenue, L-159 Livermore, CA 94550-0611 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470 From noreply at sourceforge.net Wed Dec 20 07:43:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Dec 2006 22:43:10 -0800 Subject: [ python-Bugs-1590891 ] random.randrange don't return correct value for big number Message-ID: Bugs item #1590891, was opened at 2006-11-05 11:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&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: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: MATSUI Tetsushi (mft) Assigned to: Raymond Hettinger (rhettinger) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1000000000000, -100000000000000000000, -200) 267471051174796896L Obviously, the result is not in the specified range; 1000000000000 < 267471051174796896, -100000000000000000000 < 267471051174796896 and (267471051174796896 - 1000000000000) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-20 01:43 Message: Logged In: YES user_id=80475 Originator: NO Thanks for the report. Fixed in revision 53099. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-11-08 17:22 Message: Logged In: YES user_id=4771 Oups. If the interval is very large, the step is ignored. Patch attached... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-11-08 11:45 Message: Logged In: YES user_id=341410 2.5 has the same behavior. One workaround (until it gets fixed) is to do the following... def myrandrange(start, stop, step): return start + random.randrange((stop-start)//step)*step random.randrange should change to do some variant of the above, given sane start, stop, step arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 From noreply at sourceforge.net Wed Dec 20 14:37:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 05:37:43 -0800 Subject: [ python-Bugs-1611154 ] os.path.exists("file/") failure on Solaris 9 Message-ID: Bugs item #1611154, was opened at 2006-12-07 17:25 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611154&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists("file/") failure on Solaris 9 Initial Comment: Solaris 9 and earlier fail to conform to POSIX, in that stat("FILE/") succeeds even when FILE is not a directory. POSIX says that in this case it should fail. This problem causes os.path.exists("FILE/") to succeed when it should fail, which makes it harder to write portable Python code. One of my students ran into this problem when doing a Django-based project: his code ran fine on his Linux box, but failed when he attempted to run it on the Solaris 8 server that is the standard platform for our students. To reproduce the problem, on Solaris 8 (or 9): $ touch file $ ls -l file -rw-rw-r-- 1 eggert csfac 0 Dec 7 14:19 file $ python Python 2.5 (r25:51908, Dec 7 2006, 13:14:10) [GCC 4.1.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.exists("file/") True It should be False. I'll attach a patch that works around the problem at run-time. If you prefer something that tests for it at compile time please let me know. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 08:37 Message: Logged In: YES user_id=11375 Originator: NO I think it would be sufficient to put a #ifdef ... #endif around the additional check. We don't want to make all platforms do extra system calls in order to avoid a Solaris 9 bug. Or you could write a configure test to check for this bug, but that's more complicated a task. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611154&group_id=5470 From noreply at sourceforge.net Wed Dec 20 15:46:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 06:46:13 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 09:46 Message: Logged In: YES user_id=11375 Originator: NO Attaching a patch that adds length checking: before doing a flush() on a single-file mailbox, seek to the end and verify its length is unchanged. It raises an ExternalClashError if the file's length has changed. (Should there be a different exception for this case, perhaps a subclass of ExternalClashError?) I verified that this change works by running a program that added 25 messages, pausing between each one, and then did 'echo "new line" > /tmp/mbox' from a shell while the program was running. I also noticed that the self._lookup() call in self.flush() wasn't necessary, and replaced it by an assertion. I think this change should go on both the trunk and 25-maint branches. File Added: length-checking.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 12:43 Message: Logged In: YES user_id=11375 Originator: NO Eep, correct; changing the key IDs would be a big problem for existing code. We could say 'discard all keys' after doing lock() or unlock(), but this is an API change that means the fix couldn't be backported to 2.5-maint. We could make generating the ToC more complicated, preserving key IDs when possible; that may not be too difficult, though the code might be messy. Maybe it's best to just catch this error condition: save the size of the mailbox, updating it in _append_message(), and then make .flush() raise an exception if the mailbox size has unexpectedly changed. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-16 14:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 09:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Wed Dec 20 16:53:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 07:53:05 -0800 Subject: [ python-Bugs-1284316 ] Win32: Security problem with default installation directory Message-ID: Bugs item #1284316, was opened at 2005-09-07 16:34 Message generated for change (Comment added) made by norvellspearman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&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: Installation Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mika Eloranta (mel) Assigned to: Martin v. L?wis (loewis) Summary: Win32: Security problem with default installation directory Initial Comment: (Sorry, this is a bit long since the issue is not entirely trivial.) This problem only exists on Windows operating systems installed on an NTFS file system. Confirmed on several Windows 2000, XP and Windows 2003 Server systems. All Python versions (at least 2.x) are affected. The default installation target directory where Python is installation on Windows is directly under the system drive's root directory (e.g. "C:\python24"). The file and directory permissions inherited by the python24-directory from the root directory are not secure enough for keeping application binaries. Microsoft has, in their infinite wisdom, decided that the root directory of the system drive should allow regular (non-admin) users to create directories and files there. This set of permissions is inherited by the python directory when it is created in the default location (i.e. "C:\python24" or whatever). This "feature" allows a regular (non-admin) user to perform a priviledge escalation attack for example in the following manner: 1. Figure out the name of some DLL python (or some extension .PYD) loads using LoadLibrary() without an absolute path. 2. Copy a DLL with the same name into the python-directory (this should not be allowed, but it is!) containing some code the attacker wants to run with escalated priviledges. 3. Wait until python is run by an admin in the same machine or by the LocalSystem account. How to view the problematic part of the ACL: 1. Right-click the "C:\python24" directory in Windows Explorer 2. select Properties... -> Security -> Advanced 3. In the "Permissions" tab you will see an entry for the "Users" group, it says "Special" in the "Permissions" column 4. Select the above entry and click "Edit..." 5. Well hidden? I think so, too. The fix: The proper (default) location where application binaries should be installed is under the "c:\program files\" directory. This directory has properly set permissions by default. PS. The same problem exists in ActivePerl, Ruby and many other tools. ---------------------------------------------------------------------- Comment By: Norvell Spearman (norvellspearman) Date: 2006-12-20 09:53 Message: Logged In: YES user_id=370406 Originator: NO Would installing Python to \PROGRA~1\PythonXX prevent the space-in-filename problems? This trick has (sometimes) worked for me when installing other programs that don't like spaces. Another -- albeit inelegant -- solution would be to create a PythonXX directory under "\Program Files", cut and paste it to the root directory, then install Python to it. I tested this and it seems to preserve the inherited permissions from "\Program Files" -- that is, normal users can't create files or directories in it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-12 07:26 Message: Logged In: YES user_id=21627 Lowering the priority; this is now a documented bug. ---------------------------------------------------------------------- Comment By: D. Scott Miller (dsmiller) Date: 2006-05-05 20:04 Message: Logged In: YES user_id=1517734 Here's a few possible solutions to the permissions problem that retain the idea of defaulting to an install path with no spaces without making too many assumptions about what permissions the installing admin actually wants: ----------------- Idea #1 Install by default to %systemroot%\PythonXX. Hey, Java sticks some stuff in there, right? If the idea is "this is kind of a part-of-the-OS thing, and MS does it this way for cscript.exe" then this seems to make sense. (We hope any admins who're using a %systemroot% with spaces in it know what they're doing.) Is the default name for %systemroot% different on any particular localized versions of Windows? I know it's "WINDOWS" in Japanese versions, anyway. ----------------- Idea #2 Have two folder select boxes in the installer, one for where to install Python and one for a folder from which to copy ACLs. These would default to %systemdrive%\PythonXX and %programfiles%, respectively. Have a check box to disable the ACL copying, but have it checked by default. This is still bad, as it doesn't solve the problem of being a special separate directory with its own individual ACL to maintain, but it's somewhat less bad than it is now for people who click through the installer trusting it to not open up their system to new flavors of privilege escalation. ----------------- Idea #3 Do something goofy with NTFS junctions. ----------------- Regardless of what's done, given that people expect not to have to worry about spaces these days, it may be a good idea to include an explanation/warning about the situation in the installer text. ----------------- In regards to Martin L?wis' concern about non-admin users not being able to cause the generation of .pyc files in the main Python directory tree: It's already like that on most OS's, correct? So it would just apply in cases where someone a) writes an add-on specifically targeting the Python directory tree, specifically for Windows and b) expects .pyc generation to be done later rather than scripted as part of the installation. I have no idea if that's common or not, but it seems relatively safe to break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-22 14:27 Message: Logged In: YES user_id=31435 A long time ago, Python did install (by default) under "Program Files". I changed that, because of the endless problems created by the frickin' embedded space, and rarer but subtler problems due to "Program Files" not being a DOSish 8.3 name. Overall I still think it was a good change. Note that, unlike most Windows applications (which are GUI-based), programming languages are _intended_ to be used heavily from the command line, invoked by scripts, and so on. That's what makes a space in the path endlessly error-prone. In WinXP Pro, I noticed that MS was still careful to put its own command-line/script tools (sort.exe, ipconfig.exe, cscript.exe, ..., even notepad.exe) under pure DOSish 8.3 space-free paths ;-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-22 13:09 Message: Logged In: YES user_id=21627 I completely disagree. It was wrong to give the system default binary directory a name with a space in it, on a system that doesn't provide command line argument vectors in its standard API. ---------------------------------------------------------------------- Comment By: Mika Eloranta (mel) Date: 2005-11-19 02:46 Message: Logged In: YES user_id=109057 Wow, even easy_install.exe from setuptools fails if python is installed under "c:\program files": C:\temp>easy_install C:\program: can't open file 'files\Python24\python.exe': [Errno 2] No such file or directory IMHO the root cause to all these problems is the wrong default installation directory. If the installation directory would conform to Windows guidelines, these kind of problems would have been easily spotted by python library developers. - Mika ---------------------------------------------------------------------- Comment By: Mika Eloranta (mel) Date: 2005-11-15 05:39 Message: Logged In: YES user_id=109057 Please consider these points as well: * The "program files" directory has "sensible" ACLs set by default (the defaults are different in different OS versions). If you install your application under "program files", you do not need to worry about the permissions. * The installation directory can be added to the PATH environment variable instead of typing it every time from console... * The current default installation directory is teaching python library developers bad habits of not handling Python installed into a directory that contains spaces properly. It is actually a miracle to find a third party library that installs a working script (batch file) to "python/scripts" if the python directory contains spaces. * The "program files" directory is the standard location where applications should be installed in Windows. This is what Microsoft requires in their guidelines and most applications obey them. You would not install python to "/python24" by default in Unix would you? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-08 04:48 Message: Logged In: YES user_id=21627 I disagree that the default location of Python should be c:\Program Files. The Python interpreter's path name is often typed into a terminal, batch file, etc., so it needs to be convenient to type. I agree that the permissions are problematic; the proper solution would be to give c:\python24 more restrictive permissions. You can do this yourself: in the security tab, edit the permission. In "Advanced", unselect the "Inherit permission" checkbox, and choose "copy" when asked. Then edit the permissions to your liking. I can consider supporting such permission setting during installation in the future - an invocation of cacls.exe should do. Notice that this is an incompatible change: as currently all users can create files in the tree, the .pyc files are often not created during installation, but on first use. If write permissions are denied, normal users could not cause .pyc creation anymore, causing increased startup costs unless the .pyc files are created during installation. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 01:26 Message: Logged In: YES user_id=33168 Martin, do you know anything about this? (Sorry, don't know who else might know.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470 From noreply at sourceforge.net Wed Dec 20 19:12:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 10:12:41 -0800 Subject: [ python-Bugs-1619641 ] format error in 2.5 ref.pdf in section 5.3.4 Calls Message-ID: Bugs item #1619641, was opened at 2006-12-20 13:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619641&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: 5 Private: No Submitted By: cwm42 (cwm42) Assigned to: Nobody/Anonymous (nobody) Summary: format error in 2.5 ref.pdf in section 5.3.4 Calls Initial Comment: Formatting error in Python 2.5 ref.pdf page 41, section 5.3.4 Calls, downloaded from docs.python.org on 12/20/06. The first part of the table which is centered in the html version is shifted off the right side of page and clipped. This problem occurs with both kpdf and kghostview. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619641&group_id=5470 From noreply at sourceforge.net Wed Dec 20 19:42:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 10:42:37 -0800 Subject: [ python-Bugs-1619659 ] htonl, ntohl don't handle negative longs Message-ID: Bugs item #1619659, was opened at 2006-12-20 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: htonl, ntohl don't handle negative longs Initial Comment: >>> htonl(-5) -67108865 >>> htonl(-5L) Traceback (most recent call last): File "", line 1, in ? OverflowError: can't convert negative value to unsigned long It works fine in 2.1 and 2.2, but fails in 2.3, 2.4, 2.5. htons, ntohs do not appear to have the bug, but I'm not 100% sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470 From noreply at sourceforge.net Wed Dec 20 20:10:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 11:10:05 -0800 Subject: [ python-Bugs-1619674 ] Minor error in sum() docs Message-ID: Bugs item #1619674, was opened at 2006-12-20 19:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619674&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: 5 Private: No Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Minor error in sum() docs Initial Comment: In 2.1 Built-in Functions, the docs for sum() say it takes a sequence argument. IIUC the actual requirement is for an iterable which is a weaker requirement than a sequence. For example the argument can be a generator expression or a dict, neither of which is a sequence. Also there is a missing 'a' in the fourth sentence. Here is a suggested rewrite: sum(iterable[, start]) Sums start and the items of an iterable, from left to right, and returns the total. start defaults to 0. The iterable's items are normally numbers, and are not allowed to be strings. The fast, correct way to concatenate a sequence of strings... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619674&group_id=5470 From noreply at sourceforge.net Wed Dec 20 20:17:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 11:17:54 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: David Watson (baikie) Date: 2006-12-20 19:17 Message: Logged In: YES user_id=1504904 Originator: YES Yeah, I think that should definitely go in. ExternalClashError or a subclass sounds fine to me (although you could make a whole taxonomy of these errors, really). It would be good to have the code actually keep up with other programs' changes, though; a program might just want to count the messages at first, say, and not make changes until much later. I've been trying out the second option (patch attached, to apply on top of mailbox-copy-back), regenerating _toc on locking, but preserving existing keys. The patch allows existing _generate_toc()s to work unmodified, but means that _toc now holds the entire last known contents of the mailbox file, with the 'pending' (user-visible) mailbox state being held in a new attribute, _user_toc, which is a mapping from keys issued to the program to the keys of _toc (i.e. sequence numbers in the file). When _toc is updated, any new messages that have appeared are given keys in _user_toc that haven't been issued before, and any messages that have disappeared are removed from it. The code basically assumes that messages with the same sequence number are the same message, though, so even if most cases are caught by the length check, programs that make deletions/replacements before locking could still delete the wrong messages. This behaviour could be trapped, though, by raising an exception in lock() if self._pending is set (after all, code like that would be incorrect unless it could be assumed that the mailbox module kept hashes of each message or something). Also attached is a patch to the test case, adding a lock/unlock around the message count to make sure _toc is up-to-date if the parent process finishes first; without it, there are still intermittent failures. File Added: mailbox-update-toc.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 14:46 Message: Logged In: YES user_id=11375 Originator: NO Attaching a patch that adds length checking: before doing a flush() on a single-file mailbox, seek to the end and verify its length is unchanged. It raises an ExternalClashError if the file's length has changed. (Should there be a different exception for this case, perhaps a subclass of ExternalClashError?) I verified that this change works by running a program that added 25 messages, pausing between each one, and then did 'echo "new line" > /tmp/mbox' from a shell while the program was running. I also noticed that the self._lookup() call in self.flush() wasn't necessary, and replaced it by an assertion. I think this change should go on both the trunk and 25-maint branches. File Added: length-checking.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 17:43 Message: Logged In: YES user_id=11375 Originator: NO Eep, correct; changing the key IDs would be a big problem for existing code. We could say 'discard all keys' after doing lock() or unlock(), but this is an API change that means the fix couldn't be backported to 2.5-maint. We could make generating the ToC more complicated, preserving key IDs when possible; that may not be too difficult, though the code might be messy. Maybe it's best to just catch this error condition: save the size of the mailbox, updating it in _append_message(), and then make .flush() raise an exception if the mailbox size has unexpectedly changed. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-16 19:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 14:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 13:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 21:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 20:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Wed Dec 20 20:19:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 11:19:03 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: David Watson (baikie) Date: 2006-12-20 19:19 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-test-lock.diff ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-20 19:17 Message: Logged In: YES user_id=1504904 Originator: YES Yeah, I think that should definitely go in. ExternalClashError or a subclass sounds fine to me (although you could make a whole taxonomy of these errors, really). It would be good to have the code actually keep up with other programs' changes, though; a program might just want to count the messages at first, say, and not make changes until much later. I've been trying out the second option (patch attached, to apply on top of mailbox-copy-back), regenerating _toc on locking, but preserving existing keys. The patch allows existing _generate_toc()s to work unmodified, but means that _toc now holds the entire last known contents of the mailbox file, with the 'pending' (user-visible) mailbox state being held in a new attribute, _user_toc, which is a mapping from keys issued to the program to the keys of _toc (i.e. sequence numbers in the file). When _toc is updated, any new messages that have appeared are given keys in _user_toc that haven't been issued before, and any messages that have disappeared are removed from it. The code basically assumes that messages with the same sequence number are the same message, though, so even if most cases are caught by the length check, programs that make deletions/replacements before locking could still delete the wrong messages. This behaviour could be trapped, though, by raising an exception in lock() if self._pending is set (after all, code like that would be incorrect unless it could be assumed that the mailbox module kept hashes of each message or something). Also attached is a patch to the test case, adding a lock/unlock around the message count to make sure _toc is up-to-date if the parent process finishes first; without it, there are still intermittent failures. File Added: mailbox-update-toc.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 14:46 Message: Logged In: YES user_id=11375 Originator: NO Attaching a patch that adds length checking: before doing a flush() on a single-file mailbox, seek to the end and verify its length is unchanged. It raises an ExternalClashError if the file's length has changed. (Should there be a different exception for this case, perhaps a subclass of ExternalClashError?) I verified that this change works by running a program that added 25 messages, pausing between each one, and then did 'echo "new line" > /tmp/mbox' from a shell while the program was running. I also noticed that the self._lookup() call in self.flush() wasn't necessary, and replaced it by an assertion. I think this change should go on both the trunk and 25-maint branches. File Added: length-checking.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 17:43 Message: Logged In: YES user_id=11375 Originator: NO Eep, correct; changing the key IDs would be a big problem for existing code. We could say 'discard all keys' after doing lock() or unlock(), but this is an API change that means the fix couldn't be backported to 2.5-maint. We could make generating the ToC more complicated, preserving key IDs when possible; that may not be too difficult, though the code might be messy. Maybe it's best to just catch this error condition: save the size of the mailbox, updating it in _append_message(), and then make .flush() raise an exception if the mailbox size has unexpectedly changed. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-16 19:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 14:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 13:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 21:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 20:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Wed Dec 20 20:19:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 11:19:12 -0800 Subject: [ python-Bugs-1619680 ] ctypes in_dll documented with wrong argument order Message-ID: Bugs item #1619680, was opened at 2006-12-20 11:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619680&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: 5 Private: No Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes in_dll documented with wrong argument order Initial Comment: "Python Library Reference", section 14.14.2.6 "Data types" Quote: in_dll( name, library) This method returns a ctypes type instance exported by a shared library. name is the name of the symbol that exports the data, library is the loaded shared library. The arguments are reversed, of course. I believe the attached patch for libctypes.tex corrects it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619680&group_id=5470 From noreply at sourceforge.net Wed Dec 20 20:48:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 11:48:41 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 14:48 Message: Logged In: YES user_id=11375 Originator: NO Committed length-checking.diff to trunk in rev. 53110. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-20 14:19 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-test-lock.diff ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-20 14:17 Message: Logged In: YES user_id=1504904 Originator: YES Yeah, I think that should definitely go in. ExternalClashError or a subclass sounds fine to me (although you could make a whole taxonomy of these errors, really). It would be good to have the code actually keep up with other programs' changes, though; a program might just want to count the messages at first, say, and not make changes until much later. I've been trying out the second option (patch attached, to apply on top of mailbox-copy-back), regenerating _toc on locking, but preserving existing keys. The patch allows existing _generate_toc()s to work unmodified, but means that _toc now holds the entire last known contents of the mailbox file, with the 'pending' (user-visible) mailbox state being held in a new attribute, _user_toc, which is a mapping from keys issued to the program to the keys of _toc (i.e. sequence numbers in the file). When _toc is updated, any new messages that have appeared are given keys in _user_toc that haven't been issued before, and any messages that have disappeared are removed from it. The code basically assumes that messages with the same sequence number are the same message, though, so even if most cases are caught by the length check, programs that make deletions/replacements before locking could still delete the wrong messages. This behaviour could be trapped, though, by raising an exception in lock() if self._pending is set (after all, code like that would be incorrect unless it could be assumed that the mailbox module kept hashes of each message or something). Also attached is a patch to the test case, adding a lock/unlock around the message count to make sure _toc is up-to-date if the parent process finishes first; without it, there are still intermittent failures. File Added: mailbox-update-toc.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 09:46 Message: Logged In: YES user_id=11375 Originator: NO Attaching a patch that adds length checking: before doing a flush() on a single-file mailbox, seek to the end and verify its length is unchanged. It raises an ExternalClashError if the file's length has changed. (Should there be a different exception for this case, perhaps a subclass of ExternalClashError?) I verified that this change works by running a program that added 25 messages, pausing between each one, and then did 'echo "new line" > /tmp/mbox' from a shell while the program was running. I also noticed that the self._lookup() call in self.flush() wasn't necessary, and replaced it by an assertion. I think this change should go on both the trunk and 25-maint branches. File Added: length-checking.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 12:43 Message: Logged In: YES user_id=11375 Originator: NO Eep, correct; changing the key IDs would be a big problem for existing code. We could say 'discard all keys' after doing lock() or unlock(), but this is an API change that means the fix couldn't be backported to 2.5-maint. We could make generating the ToC more complicated, preserving key IDs when possible; that may not be too difficult, though the code might be messy. Maybe it's best to just catch this error condition: save the size of the mailbox, updating it in _append_message(), and then make .flush() raise an exception if the mailbox size has unexpectedly changed. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-16 14:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 09:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Wed Dec 20 21:12:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 12:12:13 -0800 Subject: [ python-Bugs-1619674 ] Minor error in sum() docs Message-ID: Bugs item #1619674, was opened at 2006-12-20 14:10 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619674&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: Kent Johnson (kjohnson) >Assigned to: A.M. Kuchling (akuchling) Summary: Minor error in sum() docs Initial Comment: In 2.1 Built-in Functions, the docs for sum() say it takes a sequence argument. IIUC the actual requirement is for an iterable which is a weaker requirement than a sequence. For example the argument can be a generator expression or a dict, neither of which is a sequence. Also there is a missing 'a' in the fourth sentence. Here is a suggested rewrite: sum(iterable[, start]) Sums start and the items of an iterable, from left to right, and returns the total. start defaults to 0. The iterable's items are normally numbers, and are not allowed to be strings. The fast, correct way to concatenate a sequence of strings... ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 15:12 Message: Logged In: YES user_id=11375 Originator: NO Thanks for pointing this out; I've changed the description of sum in rev. 53112. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619674&group_id=5470 From noreply at sourceforge.net Wed Dec 20 21:21:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Dec 2006 12:21:40 -0800 Subject: [ python-Bugs-1619680 ] ctypes in_dll documented with wrong argument order Message-ID: Bugs item #1619680, was opened at 2006-12-20 14:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619680&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: Lenard Lindstrom (kermode) >Assigned to: A.M. Kuchling (akuchling) Summary: ctypes in_dll documented with wrong argument order Initial Comment: "Python Library Reference", section 14.14.2.6 "Data types" Quote: in_dll( name, library) This method returns a ctypes type instance exported by a shared library. name is the name of the symbol that exports the data, library is the loaded shared library. The arguments are reversed, of course. I believe the attached patch for libctypes.tex corrects it. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 15:21 Message: Logged In: YES user_id=11375 Originator: NO Thanks for pointing this out; patch applied to trunk in rev. 53117 and 2.5-maint in rev. 53118. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619680&group_id=5470 From noreply at sourceforge.net Thu Dec 21 09:51:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 00:51:01 -0800 Subject: [ python-Bugs-1586414 ] tarfile.extract() may cause file fragmentation on Windows XP Message-ID: Bugs item #1586414, was opened at 2006-10-28 23:22 Message generated for change (Settings changed) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) >Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile.extract() may cause file fragmentation on Windows XP Initial Comment: When I use tarfile.extract() to extract all the files from a large tar archive with lots of files tends to cause file fragmentation in Windows. Apparently NTFS cluster allocation interacts badly with such operations if Windows is not aware of the size of each file. The solution is to use a combination of the Win32 APIs SetFilePointer() and SetEndOfFile() before writing to the target file. This helps Windows choose a contiguous free space for the file. I tried it on the 2.6 trunk by calling file.truncate() (which seems to implement the appropriate calls on Windows) to set the file size before writing to a file. It helps to avoid fragmentation for the extracted files on my Windows XP x64 system. Can this be added to tarfile to improve its performance on Windows? ---------------------------------------------------------------------- Comment By: Enoch Julias (enochjul) Date: 2006-10-31 06:07 Message: Logged In: YES user_id=6071 I submitted patch #1587674 for this, though I am not sure if it is a good idea to use truncate() for such a purpose. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-29 09:55 Message: Logged In: YES user_id=849994 Can you try to come up with a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470 From noreply at sourceforge.net Thu Dec 21 09:51:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 00:51:01 -0800 Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency Message-ID: Bugs item #1496501, was opened at 2006-05-28 20:42 Message generated for change (Settings changed) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) >Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile.py: dict order dependency Initial Comment: When guessing the type of a file, tarfile.py tries to open it in .tar, .tar.gz and .tar.bz2 modes successfully. The problem is that in conjunction with a fileobj argument, failed attempts can advance the current position of the fileobj, and cause the following attempts to fail as well. This didn't show up so far because, by chance, the order in which the OPEN_METH dictionary is enumerated is somehow the "correct" one. The problem can be seen by changing this order and re-running test_tarfile.py; for example, reverse the order (tarfile.py line 1013): for comptype in reversed(cls.OPEN_METH): ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 19:46 Message: Logged In: YES user_id=591932 added patch 1504073 because SF won't let just anyone attach files to bugs. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 18:15 Message: Logged In: YES user_id=591932 The invidual openers could tell() the fileobj and revert with a seek() on failure. The module requires those methods be implemented already to work so that is safe. I'll cook up a patch. But basically open() isn't as extensible as it seems. Stream reading and writing isn't supported for injected compression types and appending only works on plain tarfiles. I'm guessing that isn't a problem in practice or someone would have mentioned it by now ;) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-10 12:46 Message: Logged In: YES user_id=4771 If possible, I would prefer that the constructors were fixed to become order-independent. Not sure how easy this is, though. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 21:56 Message: Logged In: YES user_id=591932 I took a look at tarfile.py and though there is this comment about OPEN_METH # This concept allows one to subclass TarFile without losing the comfort of # the super-constructor. A sub-constructor is registered and made available # by adding it to the mapping in OPEN_METH. because adding items to OPEN_METH could change the order and break the Tarfile.open() classmethod I doubt adding to OPEN_METH is done in practice. +1 for renaming OPEN_METH to _OPEN_METH and making it a list of two-tuples. +0 on changing the two tups from ('typename', 'funcname') to ('typename', function_ref) and dropping the getattr functionality. The three default openers are not listed in the public interface so if anyone is subclassing Tarfile and overriding them (doubtful) they are doing so at their own peril. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470 From noreply at sourceforge.net Thu Dec 21 09:51:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 00:51:01 -0800 Subject: [ python-Bugs-1527974 ] tarfile chokes on ipython archive on Windows Message-ID: Bugs item #1527974, was opened at 2006-07-24 23:00 Message generated for change (Settings changed) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arve Knudsen (arve_knudsen) >Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile chokes on ipython archive on Windows Initial Comment: I'm trying to extract files from the latest ipython tar archive, available from http://ipython.scipy.org/dist/ipython-0.7.2.tar.gz, using tarfile. This is on Windows XP, using Python 2.4.3. There is only a problem if I open the archive in stream mode (the "mode" argument to tarfile.open is "r|gz"), in which case tarfile raises StreamError. I'd be happy if this error could be sorted out. The following script should trigger the error: import tarfile f = file(r"ipython-0.7.2.tar.gz", "rb") tar = tarfile.open(fileobj=f, mode="r|gz") try: for m in tar: tar.extract(m) finally: tar.close() f.close( The resulting exception: Traceback (most recent call last): File "tst.py", line 7, in ? tar.extract(m) File "C:\Program Files\Python24\lib\tarfile.py", line 1335, in extract self._extract_member(tarinfo, os.path.join(path, tarinfo.name)) File "C:\Program Files\Python24\lib\tarfile.py", line 1431, in _extract_member self.makelink(tarinfo, targetpath) File "C:\Program Files\Python24\lib\tarfile.py", line 1515, in makelink self._extract_member(self.getmember(linkpath), targetpath) File "C:\Program Files\Python24\lib\tarfile.py", line 1423, in _extract_member self.makefile(tarinfo, targetpath) File "C:\Program Files\Python24\lib\tarfile.py", line 1461, in makefile copyfileobj(source, target) File "C:\Program Files\Python24\lib\tarfile.py", line 158, in copyfileobj shutil.copyfileobj(src, dst) File "C:\Program Files\Python24\lib\shutil.py", line 22, in copyfileobj buf = fsrc.read(length) File "C:\Program Files\Python24\lib\tarfile.py", line 551, in _readnormal self.fileobj.seek(self.offset + self.pos) File "C:\Program Files\Python24\lib\tarfile.py", line 420, in seek raise StreamError, "seeking backwards is not allowed" tarfile.StreamError: seeking backwards is not allowed ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2006-07-27 00:20 Message: Logged In: YES user_id=1522083 Regarding my last comment, sorry about the noise. After giving it some more thought I realized it was not very realistic implementation wise, seeing as you can't know whether a file is being linked to when you encounter it in the stream (right?). So I followed your suggestion instead and handled the links on the client level. What I think I'd like to see in TarFile though is an 'extractall' method with the ability to report progress to an optional callback, since I'm only opening in stream mode as a hack to implement this myself (by monitoring file position). From browsing tarfile's source it seems it might require some effort though (with e.g. BZ2File you can't know the amount of data without decompressing everything?). ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2006-07-25 11:58 Message: Logged In: YES user_id=1522083 Yes I admit that is a weakness to my proposed approach. Perhaps it would be a better idea to extract hardlinked files to a temporary location and copy those files when needed, as a cache? The only problem that I can think of with this approach is the overhead, but perhaps this could be configurable through a keyword if you think it would pose a significant problem (i.e. keeping extra copies of potentially huge files)? The temporary cache would be private to tarfile, so there should be no need to worry about modifications to the contained files. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-25 11:31 Message: Logged In: YES user_id=642936 Copying the previously extracted file is no option. When the archive is extracted inside a loop, you never know what happens between two extract() calls. The original file could have been renamed, changed or removed. Suppose you want to extract just those members which are hard links: for tarinfo in tar: if tarinfo.islnk(): tar.extract(tarinfo) I agree with you that the error message is bad because it does not give the slightest idea of what's going wrong. I'll see what I can do about that. To work around your particular problem, my idea is to subclass the TarFile class and replace the makelink() method with one that simply copies the file as you proposed. ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2006-07-25 10:59 Message: Logged In: YES user_id=1522083 Thanks for the clarification, Lars. I'd prefer to continue with my current approach however, since it allows me to report progress as the tarfile is unpacked/decompressed. Also, I don't think it would be satisfactory at all if tarfile would just die with a mysterious error in such cases. In order to resolve this, why must tarfile extract the file again, can't it copy the already extracted file? ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-25 10:42 Message: Logged In: YES user_id=642936 The traceback tells me that there is a hard link inside the archive which means that a file in the archive is referenced to twice. This hard link can be extracted only on platforms that have an os.link() function. On Win32 they're not supported by the file system, but tarfile works around this by extracting the referenced file twice. In order to extract the file the second time it is necessary that tarfile seeks back in the input file to access the file's data again. But "seeking backwards is not allowed" when a file is opened in streaming mode ;-) If you do not necessarily need streaming mode for your application, better use "r:gz" or "r" and the problem will be gone. ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2006-07-25 10:04 Message: Logged In: YES user_id=1522083 Ok, I've verified now that the problem persists with Python 2.4.4 (from the 2.4 branch in svn). The exact same thing happens. ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2006-07-25 09:29 Message: Logged In: YES user_id=1522083 Well yeah, it appears to be Windows specific. I just tested on Linux (Ubuntu), also with Python 2.4.3. I'll try 2.4.3+ on Windows to see if it makes any difference. Come to think of it I think I experienced this problem in that past on Linux, but then I solved it by repacking ipython. Also, if I pack it myself on Windows using bsdtar it works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 05:35 Message: Logged In: YES user_id=33168 I tested this on Linux with both 2.5 and 2.4.3+ without problems. I believe there were some fixes in this area. Could you try testing with the 2.4.3+ current which will become 2.4.4 (or 2.5b2)? If this is still a problem, it looks like it may be Windows specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527974&group_id=5470 From noreply at sourceforge.net Thu Dec 21 09:51:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 00:51:02 -0800 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Settings changed) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Blais (blais) >Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile local name is local, should be abspath Initial Comment: I ran into a bug using the tarfile module with compression from a directory that did not exist anymore, and this exhibits a bug in the tarfile module. I'm not completely sure how to fix it with certainty, so instead of filing a quick patch, I submit a bug so people familiar with the module can have a look first. The problem is that when you open a tarfile with gz or bz2 compression, the TarFile object is opened with a filename that is not absolute, just local (basename is called) but the actual file is using a file-like object. Now, when you add a new entry, there is a check in the TarFile.add method that checks if we're not adding the archive itself into the tarfile, and this method calls abspath. Calling abspath on the name that has been basename'd is incorrect and a bug. It happens not to fail nor cause any problems when called from an existing directory (the test returns false), but it does not do the job it is supposed to. When the CWD has been deleted, calling abspath fails with an OSError, which brings out the problem. Some code to reproduce the bug is provided in an attachment. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-25 11:04 Message: Logged In: YES user_id=1188172 The patch has been reversed, so reopening. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 08:08 Message: Logged In: YES user_id=21627 This was fixed with said patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. ---------------------------------------------------------------------- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Thu Dec 21 09:51:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 00:51:02 -0800 Subject: [ python-Bugs-1362587 ] Problem with tapedevices and the tarfile module Message-ID: Bugs item #1362587, was opened at 2005-11-21 08:44 Message generated for change (Settings changed) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Henrik (esshenrik) >Assigned to: Lars Gust?bel (gustaebel) Summary: Problem with tapedevices and the tarfile module Initial Comment: Problem to read a archive from tape that was created with the tarfile module in python. Error: >>> tar = tarfile.open("/dev/st0", "r") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/tarfile.py", line 916, in open return func(name, "r", fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 933, in taropen return cls(name, mode, fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 811, in __init__ fileobj = file(self.name, self.mode) IOError: [Errno 16] Device or resource busy: '/dev/st0' I was creating the archive with succes: >>> tar.close() >>> tar = tarfile.open("/dev/st0", "w") >>> tar.add("/tmp/bin1.tar") >>> tar.add("/tmp/bin2.tar") >>> tar.close() >>> When I try to read the tape without pyton the folowing error: [root at localhost tmp]# tar tvbf 20 /dev/st0 tar: Record size = 8 blocks -rw-r--r-- root/root 128614400 2005-11-20 19:53:11 tmp/bin1.tar tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory ...... Can anyone help me with this problem or have another module for tarfile that works with tapedevices? /Henrik ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-03 14:31 Message: Logged In: YES user_id=21627 Lowering priority, as the issue doesn't appear that urgent. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-11-21 09:40 Message: Logged In: YES user_id=642936 Could try and use tarfile's stream interface for writing and reading and see if that works? Just append a pipe symbol to the mode, e.g.: tar = tarfile.open("/dev/st0", "w|") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 From noreply at sourceforge.net Thu Dec 21 15:09:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 06:09:09 -0800 Subject: [ python-Bugs-411881 ] Use of "except:" in logging module Message-ID: Bugs item #411881, was opened at 2001-03-28 07:58 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&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: Python Library Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Itamar Shtull-Trauring (itamar) >Assigned to: Vinay Sajip (vsajip) >Summary: Use of "except:" in logging module Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 09:09 Message: Logged In: YES user_id=11375 Originator: NO Raymond said (in 2003) most of the remaining except: statements looked reasonable, so I'm changing this bug's summary to refer to the logging module and reassigning to vsajip. PEP 8 doesn't say anything about bare excepts; I'll bring this up on python-dev. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-13 06:21 Message: Logged In: YES user_id=80475 Hold-off on logging for a bit. Vinay Sajip has other patches already under review. I'll ask him to fix-up the bare excepts in conjuction with those patches. For the other modules, patches are welcome. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-11 15:54 Message: Logged In: YES user_id=6380 You're right. The logging module uses more blank except: clauses than I'm comfortable with. Anyone want to upload a patch set? ---------------------------------------------------------------------- Comment By: Grant Monroe (gmonroe) Date: 2003-12-11 15:50 Message: Logged In: YES user_id=929204 A good example of an incorrect use of a blanket "except:" clause is in __init__.py in the logging module. The emit method of the StreamHandler class should special case KeyboardInterrupt. Something like this: try: .... except KeyboardInterrupt: raise except: self.handleError(record) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 22:47 Message: Logged In: YES user_id=80475 Some efforts were made to remove many bare excepts prior to Py2.3a1. Briefly scanning those that remain, it looks like many of them are appropriate or best left alone. I recommend that this bug be closed unless someone sees something specific that demands a change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-13 23:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 15:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-12 03:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 14:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-23 01:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 16:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-08-11 11:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 03:11 Message: Logged In: YES user_id=3066 Fixed modules mhlib and rfc822 (SF is having a problem generating the checkin emails, though). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-11 15:40 Message: Logged In: YES user_id=3066 OK, I've fixed up a few more modules: anydbm chunk formatter htmllib mailcap pre pty I made one change to asyncore as well, but other bare except clauses remain there; I'm not sufficiently familiar with that code to just go digging into those. I also fixed an infraction in pstats, but left others for now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-23 04:14 Message: Logged In: YES user_id=31435 Ping's intent is that pydoc work under versions of Python as early as 1.5.2, so that sys._getframe is off-limits in pydoc and its supporting code (like inspect.py). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-04-23 03:32 Message: Logged In: YES user_id=21627 For inspect.py, why is it necessary to keep the old code at all? My proposal: remove currentframe altogether, and do currentframe = sys._getframe unconditionally. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-22 10:52 Message: Logged In: YES user_id=32065 I submitted a 4th patch. I'm starting to run out of easy cases... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-04-19 05:15 Message: Logged In: YES user_id=44345 I believe the following patch is correct for the try/except in inspect.currentframe. Note that it fixes two problems. One, it avoids a bare except. Two, it gets rid of a string argument to the raise statement (string exceptions are now deprecated, right?). *** /tmp/skip/inspect.py Thu Apr 19 04:13:36 2001 --- /tmp/skip/inspect.py.~1.16~ Thu Apr 19 04:13:36 2001 *************** *** 643,650 **** def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! 1/0 ! except ZeroDivisionError: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe --- 643,650 ---- def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! raise 'catch me' ! except: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-17 11:27 Message: Logged In: YES user_id=32065 inspect.py uses sys_getframe if it's there, the other code is for backwards compatibility. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 13:24 Message: Logged In: YES user_id=6380 Actually, inspect.py should use sys._getframe()! And yes, KeyboardError is definitely one of the reasons why this is such a bad idiom... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2001-04-11 13:15 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 11:45 Message: Logged In: YES user_id=6380 I've applied the three patches you supplied. I agree with Martin that to do this right we'll have to tread carefully. But please go on! (No way more of this will find its way into 2.1 though.) ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-03-30 05:54 Message: Logged In: YES user_id=32065 inspect.py should be removed from this list, the use is correct. In general, I just submitted this bug so that when people are editing a module they'll notice these things, since in some cases only someone who knows the code very well can know if the "expect:" is needed or not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-03-30 01:59 Message: Logged In: YES user_id=21627 Can you identify modules where catching everything is incorrect, and propose changes to correct them. This should be done one-by-one, with careful analysis in each case, and may take well months or years to complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply at sourceforge.net Thu Dec 21 15:44:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 06:44:24 -0800 Subject: [ python-Bugs-1362587 ] Problem with tapedevices and the tarfile module Message-ID: Bugs item #1362587, was opened at 2005-11-21 08:44 Message generated for change (Settings changed) made by esshenrik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&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: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Henrik (esshenrik) Assigned to: Lars Gust?bel (gustaebel) Summary: Problem with tapedevices and the tarfile module Initial Comment: Problem to read a archive from tape that was created with the tarfile module in python. Error: >>> tar = tarfile.open("/dev/st0", "r") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/tarfile.py", line 916, in open return func(name, "r", fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 933, in taropen return cls(name, mode, fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 811, in __init__ fileobj = file(self.name, self.mode) IOError: [Errno 16] Device or resource busy: '/dev/st0' I was creating the archive with succes: >>> tar.close() >>> tar = tarfile.open("/dev/st0", "w") >>> tar.add("/tmp/bin1.tar") >>> tar.add("/tmp/bin2.tar") >>> tar.close() >>> When I try to read the tape without pyton the folowing error: [root at localhost tmp]# tar tvbf 20 /dev/st0 tar: Record size = 8 blocks -rw-r--r-- root/root 128614400 2005-11-20 19:53:11 tmp/bin1.tar tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory ...... Can anyone help me with this problem or have another module for tarfile that works with tapedevices? /Henrik ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-03 14:31 Message: Logged In: YES user_id=21627 Lowering priority, as the issue doesn't appear that urgent. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-11-21 09:40 Message: Logged In: YES user_id=642936 Could try and use tarfile's stream interface for writing and reading and see if that works? Just append a pipe symbol to the mode, e.g.: tar = tarfile.open("/dev/st0", "w|") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 From noreply at sourceforge.net Thu Dec 21 15:48:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 06:48:07 -0800 Subject: [ python-Bugs-436259 ] [Windows] exec*/spawn* problem with spaces in args Message-ID: Bugs item #436259, was opened at 2001-06-25 23:17 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&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: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: [Windows] exec*/spawn* problem with spaces in args Initial Comment: DOS and Windows processes are not given an argument vector, as Unix processes are; instead they are given a command line and are expected to perform any necessary argument parsing themselves. Each C run-time library must convert command lines into argument vectors for the main() function, and if it includes exec* and spawn* functions then those must convert argument vectors into a command-line. Naturally, the various implementations differ in interesting ways. The Visual C++ run-time library (MSVCRT) implementation of the exec* and spawn* functions is particularly awful in that it simply concatenates the strings with spaces in-between (see source file cenvarg.c), which means that arguments with embedded spaces are likely to turn into multiple arguments in the new process. Obviously, when Python is built using Visual C++, its os.exec* and os.spawn* functions behave in this way too. MS prefers to work around this bug (see Knowledge Base article Q145937) rather than to fix it. Therefore I think Python must work around it too when built with Visual C++. I experimented with MSVCRT and Cygwin (using the attached program print_args.c) and could not find a way to convert an argument vector into a command line that they would both convert back to the same argument vector, but I got close. MSVCRT's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes must be escaped by preceding them with a backslash. If an argument contains literal backslashes before a literal or delimiting double-quote, those backslashes must be escaped by doubling them. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Cygwin's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes may be escaped by preceding them with a backslash, but then they count as enclosing double-quote as well, which appears to be a bug. They may also be escaped by doubling them, in which case they must be enclosed in double-quotes; since MSVCRT does not accept this, it's useless. As far as I can see, literal backslashes before a literal double-quote must not be escaped and literal backslashes before an enclosing double-quote *cannot* be escaped. It's really quite hard to understand what its rules are for backslashes and double-quotes, and I think it's broken. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Here's a Python version of a partial fix for use in nt.exec* and nt.spawn*. This function modifies argument strings so that the resulting command line will satisfy programs that use MSVCRT, and programs that use Cygwin if that's possible. def escape(arg): import re # If arg contains no space or double-quote then # no escaping is needed. if not re.search(r'[ "]', arg): return arg # Otherwise the argument must be quoted and all # double-quotes, preceding backslashes, and # trailing backslashes, must be escaped. def repl(match): if match.group(2): return match.group(1) * 2 + '\\"' else: return match.group(1) * 2 return '"' + re.sub(r'(\\*)("|$)', repl, arg) + '"' This could perhaps be used as a workaround for the problem. Unfortunately it would conflict with workarounds implemented at the Python level (which I have been using for a while). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 09:48 Message: Logged In: YES user_id=11375 Originator: NO Does this argument-line parsing weirdness still have relevance to current MSVC runtimes? Changing os.spawn() seems like a non-starter because it'll break existing code; the Python landscape has changed and subprocess.py is a higher-level, more useful way to run subprocesses (it has a MS C runtime-alike function, list2cmdline). Unless someone submits a patch to change _nt_quote_args in distutils/spawn.py, I'll close this bug in a few months (the next time I visit the really old bugs). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-12 00:57 Message: Logged In: YES user_id=31435 distutils is *trying* to make spawn work the same way across platforms, via spawn.py. Help it! You're not likely to get anywhere with a change to the os.spawn family because you already know it will break code -- and it will break disutils in particular. If you want to break code, this needs a PEP first: write up your "two stage" approach in PEP and let the community have at it. If you read c.l.py, you should have a feel for how warmly that's likely to be received <wink>. The bit about __argv was just FYI (you seemed unaware of it; I agree it's irrelevant to what you want to achieve). ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2001-07-12 00:30 Message: Logged In: YES user_id=203860 "Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead." This is irrelevant. The OS passes the command line into a process as a single string, which it makes accessible through the GetCommandLine() function. The argument vector received by main() or accessible as __argv is generated from this by the C run-time library. "The right way to address this is to add more smarts to spawn.py in distutils" I disagree. The right thing to do is to make these functions behave in the same way across platforms, as far as possible. Perhaps this could be done in two stages - in the first release, make the fix optional, and in the second, use it all the time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 22:32 Message: Logged In: YES user_id=31435 Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead. I agree the space behavior sucks regardless. However, as you've discovered, there's nothing magical we can do about it without breaking the workarounds people have already developed on their own -- including distutils. The right way to address this is to add more smarts to spawn.py in distutils, then press to adopt that in the std library (distutils already does *some* magical arg quoting on win32 systems, and could use your help to do a better job of it). Accordingly, I added [Windows] to the summary line, changed the category to distutils, and reassigned to Greg Ward for consideration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 From noreply at sourceforge.net Thu Dec 21 15:50:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 06:50:30 -0800 Subject: [ python-Bugs-469773 ] Write 'Using Python on Platform X' documents Message-ID: Bugs item #469773, was opened at 2001-10-10 02:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=469773&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: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Write 'Using Python on Platform X' documents Initial Comment: Some stuff that's in the man page (e.g. the syntax for the -W switch) doesn't appear to be in the HTML documentation. If it is there, it's _very_ well hidden away. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 09:50 Message: Logged In: YES user_id=11375 Originator: NO Changing summary to be more accurate. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-11-11 02:27 Message: Logged In: YES user_id=29957 What about instead a new "Using Python" document. There's a bunch of overlap between the platforms. We can then also have separate chapters for Mac, Win, Unix. I think trying to produce platform specific docs is going to be a headache in the long run. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-11-11 01:33 Message: Logged In: YES user_id=3066 I'll note that the "Macintosh Library Modules" document deals with this sort of issue for the Mac (though it may be out of date for Mac OS X; not sure). The first chapter is an introduction to using Python on the Mac, and the remaining chapters provide module reference documentation. What's needed is something like the first chapter of that for Unix and Windows. I'm not sure where it should go, though; I don't want that material in the main library reference. This almost makes me want three platform-specific documents, one for Windows, one for Unix, and the existing Mac OS document, each containing the relevant "Using Python on ..." chapter, followed by chapters containing platform-specific modules. Modules that apply to two or more of the platforms would continue to be documented in the main library reference. The distutils modules are already documented in the distutils documentation as well. This should be fine since the "global" module index is the normal general entry point anyway. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-25 02:17 Message: Logged In: YES user_id=29957 See, that's the problem :) It's not clear where this might go - it's almost a "Using Python" section, which, as far as I can see, doesn't really exist. This might also include stuff about the Windows GUI and other interfaces for using python. If a shorter-term "just get the -W stuff in" approach is wanted, then extended the lib/module-warnings might be the approach... but it really does seem like it needs to be somewhere central. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-10-24 22:12 Message: Logged In: YES user_id=3066 I agree. Where would you suggest the information be added? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=469773&group_id=5470 From noreply at sourceforge.net Thu Dec 21 15:52:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 06:52:55 -0800 Subject: [ python-Feature Requests-502236 ] Asynchronous exceptions between threads Message-ID: Feature Requests item #502236, was opened at 2002-01-11 03:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=502236&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: Extension Modules >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) >Summary: Asynchronous exceptions between threads Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 09:52 Message: Logged In: YES user_id=11375 Originator: NO Changing summary to be clearer; reclassifying as 'Feature Request' type. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2002-01-15 14:40 Message: Logged In: YES user_id=72053 I don't feel qualified to write such a PEP. You guys are more on top of this than I am. Maybe there's no portable way to do asynchronous exceptions between threads. I don't know what happens if you hit ctrl-C when running a multi- threaded Linux program. I don't think ctrl-C even works in Windows--all you can really do is bring up the task manager and blow away the whole process. But I think asynchronous exceptions are worth having even if they're OS specific and only work on some systems. As for how a thread can exit the whole program, I thought Guido's first message (saying raise some asynchronous exception in all the threads) sounded fine, if it's feasible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 14:33 Message: Logged In: YES user_id=6380 (1) I think subclassing SystemExit can work. (2) But the difference is that killing the main thread without giving it a chance to clean up is worse than killing another thread. Does anybody want to write a PEP on thread cancellation? It sure looks like a hairy issue! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-14 03:40 Message: Logged In: YES user_id=21627 On (1): This is quite unfortunate, as I do think sys.exit and thread.exit should do different things. There would be approaches of further subclassing SystemExit; preserving the property that raising SystemExit in a thread exits the thread only - would such a solution be acceptable? On (2): This is no different from raising SystemExit in the main thread, which also does not invoke finally clauses in other threads. I don't think there can be a complete, reliable implementation of thread cancellation, only a best-effort approach. For POSIX, I'd suggest sending SIGUSR2 to each thread through pthread_kill. We might need to add a mechanism indicating whether a thread is ready to be cancelled, similar to the POSIX cancellation points. That would prevent the signal from arriving in an arbitrary library function, and defer thread termination until the library function completes. For blocking system calls, sending signals would need to be activated explicitly, to allow aborting them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-12 15:03 Message: Logged In: YES user_id=6380 (1) It's too late to change the meaning of SystemExit -- people are relying on SystemExit exiting the thread only. (2) If we provide a way for a thread to exit the whole program, how will finally clauses in other threads (including the main thread) be executed? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-11 20:05 Message: Logged In: YES user_id=21627 Tim, I'm not surprised that raising SystemExit in a thread fails to exit Python; the reason simply is that threadmodule.c:t_bootstrap choses to ignore PyExc_SystemExit, when it instead should invoke PyErr_PrintEx instead. The bug is obviously that exit_thread also raises SystemExit, when people apparently really want sys.exit and thread.exit to be two different things. So I think thread.exit should raise ThreadExit, and raising SystemExit in a thread should cause Py_Exit to be invoked (along with all other necessary cleanup). In short, 2.12 of threadmodule.c was wrong, IMO. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-11 16:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may <wink> have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-11 11:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 10:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=502236&group_id=5470 From noreply at sourceforge.net Thu Dec 21 16:13:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 07:13:16 -0800 Subject: [ python-Bugs-539175 ] resolver not thread safe Message-ID: Bugs item #539175, was opened at 2002-04-04 04:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&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: Threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: dustin sallings (dustin) Assigned to: Nobody/Anonymous (nobody) Summary: resolver not thread safe Initial Comment: I've got an application that does SNMP monitoring and has a thread listening with SimpleXMLRPCServer for remote control. I noticed the XMLRPC listener logging an incorrect address while snmp jobs were processing: sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2 HTTP/1.0" 200 - localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST /RPC2 HTTP/1.0" 200 - sw1 is one of the machines that is being queried, but the XMLRPC requests are happening over localhost. gethostbyname() and gethostbyaddr() both return static data, thus they aren't reentrant. As a workaround, I copied socket.py to my working directory and added the following to it: try: import threading except ImportError, ie: sys.stderr.write(str(ie) + "\n") # mutex for DNS lookups __dns_mutex=None try: __dns_mutex=threading.Lock() except NameError: pass def __lock(): if __dns_mutex!=None: __dns_mutex.acquire() def __unlock(): if __dns_mutex!=None: __dns_mutex.release() def gethostbyaddr(addr): """Override gethostbyaddr to try to get some thread safety.""" rv=None try: __lock() rv=_socket.gethostbyaddr(addr) finally: __unlock() return rv def gethostbyname(name): """Override gethostbyname to try to get some thread safety.""" rv=None try: __lock() rv=_socket.gethostbyname(name) finally: __unlock() return rv ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 10:13 Message: Logged In: YES user_id=11375 Originator: NO Attaching the test script. The script now fails because some of the spy.net addresses are resolved to hostnames such as adsl-69-230-8-158.dsl.pltn13.pacbell.net. When I changed the test script to use python.org machine names and ran it with Python 2.5 on Linux, no errors were reported. Does this still fail on current OS X? If not, I suggest calling this a platform C library bug and closing this report. File Added: resolv-bug.py ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-08-11 15:27 Message: Logged In: YES user_id=43919 No, unfortunately, I haven't been able to look at it in a while. Short of locking it in python, I wasn't able to avoid the failure. I'm sorry I haven't updated this at all. As far as I can tell, it's still a problem, but I haven't not been able to find a solution in the C code. I supposely I spoke with too much haste when I said I was perfectly capable of fixing the problem myself. The locking in the C code did seem correct, but the memory was still getting stomped. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 11:04 Message: Logged In: YES user_id=33168 Dustin, any progress on a patch or diagnosing this further? ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-04-05 16:44 Message: Logged In: YES user_id=43919 I first noticed this problem on my OS X box. Since it's affecting me, it's not obvious to anyone else, and I'm perfectly capable of fixing it myself, I'll try to spend some time figuring out what's going on this weekend. It seems like it might be making a decision to not use the lock at compile time. I will investigate further and submit a patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-05 16:31 Message: Logged In: YES user_id=31435 Just a reminder that the first thing to try on any SGI box is to recompile Python with optimization disabled. I can't remember the last time we had "a Python bug" on SGI that wasn't traced to a compiler -O bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-05 03:56 Message: Logged In: YES user_id=21627 Can you spot the error in the Python socket module? I still fail to see our bug, and I would assume it is a C library bug; I also cannot reproduce the problem on any of my machines. Can you please report the settings of the various HAVE_ defines for irix? ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-04-04 17:21 Message: Logged In: YES user_id=43919 Looking over the code a bit more, I see that my last message wasn't entirely accurate. There does seem to be only one lock for both gethostbyname and gethostbyaddr (gethostbyname_lock is used for both). This is a pretty simple test that illustrates the problem I'm seeing. My previous work was on my OS X machine, but this is Python 2.2 (#3, Mar 6 2002, 18:30:37) [C] on irix6. #!/usr/bin/env python # # Copyright (c) 2002 Dustin Sallings <dustin at spy.net> # $Id$ import threading import socket import time class ResolveMe(threading.Thread): hosts=['propaganda.spy.net', 'bleu.west.spy.net', 'mail.west.spy.net'] def __init__(self): threading.Thread.__init__(self) self.setDaemon(1) def run(self): # Run 100 times for i in range(100): for h in self.hosts: nrv=socket.gethostbyname_ex(h) arv=socket.gethostbyaddr(nrv[2][0]) try: # Verify the hostname is correct assert(h==nrv[0]) # Verify the two hostnames match assert(nrv[0]==arv[0]) # Verify the two addresses match assert(nrv[2]==arv[2]) except AssertionError: print "Failed! Checking " + `h` + " got, " \ + `nrv` + " and " + `arv` if __name__=='__main__': for i in range(1,10): print "Starting " + `i` + " threads." threads=[] for n in range(i): rm=ResolveMe() rm.start() threads.append(rm) for t in threads: t.join() print `i` + " threads complete." time.sleep(60) The output looks like this: verde:/tmp 190> ./pytest.py Starting 1 threads. 1 threads complete. Starting 2 threads. Failed! Checking 'propaganda.spy.net' got, ('mail.west.spy.net', [], ['66.149.231.226']) and ('mail.west.spy.net', [], ['66.149.231.226']) Failed! Checking 'bleu.west.spy.net' got, ('mail.west.spy.net', [], ['66.149.231.226']) and ('mail.west.spy.net', [], ['66.149.231.226']) [...] ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-04-04 16:08 Message: Logged In: YES user_id=43919 The XMLRPC request is clearly being logged as coming from my cisco switch when it was, in fact, coming from localhost. I can't find any clear documentation, but it seems that on at least some systems gethostbyname and gethostbyaddr reference the same static variable, so having separate locks for each one (as seen in socketmodule.c) doesn't help anything. It's not so much that they're not reentrant, but you can't call any combination of the two of them at the same time. Here's some test code: #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <assert.h> int main(int argc, char **argv) { struct hostent *byaddr, *byname; unsigned int addr; struct sockaddr *sa = (struct sockaddr *)&addr; addr=1117120483; byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET); assert(byaddr); printf("byaddr: %s\n", byaddr->h_name); byname=gethostbyname("mail.west.spy.net"); assert(byname); printf("byname: %s\n", byname->h_name); printf("\nReprinting:\n\n"); printf("byaddr: %s\n", byaddr->h_name); printf("byname: %s\n", byname->h_name); } ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-04 15:06 Message: Logged In: YES user_id=21627 I'm not sure what problem you are reporting. Python does not attempt to invoke gethostbyname from two threads simultaneously; this is prevented by the GIL. On some systems, gethostname is reentrant (in the gethostname_r incarnation); Python uses that where available, and releases the GIL before calling it. So I fail to see the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470 From noreply at sourceforge.net Thu Dec 21 16:16:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 07:16:56 -0800 Subject: [ python-Feature Requests-665194 ] datetime-RFC2822 roundtripping Message-ID: Feature Requests item #665194, was opened at 2003-01-09 13:24 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=665194&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: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 10:16 Message: Logged In: YES user_id=11375 Originator: NO Moving to feature requests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-26 12:56 Message: Logged In: YES user_id=89016 time.strptime() is locale aware, but RFC1123 & RFC822 require english day and month names, so time.strptime() can't be used as-is. (And of course time.strptime() only works for formatting, not for parsing) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-23 18:46 Message: Logged In: YES user_id=357491 time.strptime doesn't solve your problem? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-13 08:05 Message: Logged In: YES user_id=89016 totimestamp() should be the inverse of fromtimestamp(), i.e. foo.totimestamp() should be the same as time.mktime(foo.timetuple()). datetime.datetime.totimestamp() should raise OverflowError iff time.mktime() raises OverflowError. But as this may lose precision, I'd say it would be better, if datetime supported RFC1123 conversion directly, i.e. two methods frommime() and tomime(), that parse and format strings like "Sun, 06 Nov 1994 08:49:37 GMT" (what rfc822.parsedate() and rfc822.formatdate() do) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 11:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-11 07:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 00:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=665194&group_id=5470 From noreply at sourceforge.net Thu Dec 21 16:35:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 07:35:59 -0800 Subject: [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 09:41 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 10:35 Message: Logged In: YES user_id=11375 Originator: NO Preserving the argument number seems difficult without exception chaining; perhaps a middle group would be to only replace TypeError exceptions. Walter's comment at 2003-01-30 06:29 shows this can still be fooled, but a fix for 90% of the cases is still better than a fix for 0% of them. The patch looks OK, but I think it should be reworked to take the middle-ground approach, replacing only TypeErrors. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-30 06:29 Message: Logged In: YES user_id=89016 Trapping only TypeError won't help: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile(42) s = reduce(operator.add, f) Here the open call will raise a TypeError, that is totally unrelated to the iterator protocol. The cleanest solution would really be exception chaining. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-28 18:59 Message: Logged In: YES user_id=80475 One way to mitigate the information loss is to mimic the style in zip() which only traps TypeErrors but passes through things like the IOError in your original example. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-28 15:38 Message: Logged In: YES user_id=89016 Attached is a patch that fixes reduce(), map() and zip(). Unfortunately this loses the information about which argument triggered the exception (in map() and zip()) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 23:00 Message: Logged In: YES user_id=80475 There's a lot of this going around. map() and zip() have the same issue. I recommend fixing them all. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-13 08:18 Message: Logged In: YES user_id=89016 The point is that Python/bltinmodule.c/builtin_reduce() masks the error returned from PyObject_GetIter(). Errors from PyIter_Next() are not masked. What about the following example: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile("does not exist") s = reduce(operator.add, f) LazyFile *does* support iteration, but the underlying problem of the non existing file is masked. Removing the call PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration"); in builtin_reduce(), will produce the original exception "IOError: [Errno 2] No such file or directory: 'does not exist'" and when the second argument is not iteratable, the original exception is just as good: >>> reduce(lambda x,y: x+y, 42) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: iteration over non-sequence ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last): &nbsp;&nbsp;File "<stdin>", line 1, in ? &nbsp;&nbsp;File "<stdin>", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply at sourceforge.net Fri Dec 22 05:24:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 20:24:34 -0800 Subject: [ python-Bugs-539175 ] resolver not thread safe Message-ID: Bugs item #539175, was opened at 2002-04-04 01:54 Message generated for change (Comment added) made by dustin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&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: Threads Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: dustin sallings (dustin) Assigned to: Nobody/Anonymous (nobody) Summary: resolver not thread safe Initial Comment: I've got an application that does SNMP monitoring and has a thread listening with SimpleXMLRPCServer for remote control. I noticed the XMLRPC listener logging an incorrect address while snmp jobs were processing: sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2 HTTP/1.0" 200 - localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST /RPC2 HTTP/1.0" 200 - sw1 is one of the machines that is being queried, but the XMLRPC requests are happening over localhost. gethostbyname() and gethostbyaddr() both return static data, thus they aren't reentrant. As a workaround, I copied socket.py to my working directory and added the following to it: try: import threading except ImportError, ie: sys.stderr.write(str(ie) + "\n") # mutex for DNS lookups __dns_mutex=None try: __dns_mutex=threading.Lock() except NameError: pass def __lock(): if __dns_mutex!=None: __dns_mutex.acquire() def __unlock(): if __dns_mutex!=None: __dns_mutex.release() def gethostbyaddr(addr): """Override gethostbyaddr to try to get some thread safety.""" rv=None try: __lock() rv=_socket.gethostbyaddr(addr) finally: __unlock() return rv def gethostbyname(name): """Override gethostbyname to try to get some thread safety.""" rv=None try: __lock() rv=_socket.gethostbyname(name) finally: __unlock() return rv ---------------------------------------------------------------------- >Comment By: dustin sallings (dustin) Date: 2006-12-21 20:24 Message: Logged In: YES user_id=43919 Originator: YES I'll go ahead and close it. It does not fail under 2.4 on any of my machines (tried OS X/intel, PPC G3, and FreeBSD/intel). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 07:13 Message: Logged In: YES user_id=11375 Originator: NO Attaching the test script. The script now fails because some of the spy.net addresses are resolved to hostnames such as adsl-69-230-8-158.dsl.pltn13.pacbell.net. When I changed the test script to use python.org machine names and ran it with Python 2.5 on Linux, no errors were reported. Does this still fail on current OS X? If not, I suggest calling this a platform C library bug and closing this report. File Added: resolv-bug.py ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-08-11 12:27 Message: Logged In: YES user_id=43919 No, unfortunately, I haven't been able to look at it in a while. Short of locking it in python, I wasn't able to avoid the failure. I'm sorry I haven't updated this at all. As far as I can tell, it's still a problem, but I haven't not been able to find a solution in the C code. I supposely I spoke with too much haste when I said I was perfectly capable of fixing the problem myself. The locking in the C code did seem correct, but the memory was still getting stomped. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 08:04 Message: Logged In: YES user_id=33168 Dustin, any progress on a patch or diagnosing this further? ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-04-05 13:44 Message: Logged In: YES user_id=43919 I first noticed this problem on my OS X box. Since it's affecting me, it's not obvious to anyone else, and I'm perfectly capable of fixing it myself, I'll try to spend some time figuring out what's going on this weekend. It seems like it might be making a decision to not use the lock at compile time. I will investigate further and submit a patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-05 13:31 Message: Logged In: YES user_id=31435 Just a reminder that the first thing to try on any SGI box is to recompile Python with optimization disabled. I can't remember the last time we had "a Python bug" on SGI that wasn't traced to a compiler -O bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-05 00:56 Message: Logged In: YES user_id=21627 Can you spot the error in the Python socket module? I still fail to see our bug, and I would assume it is a C library bug; I also cannot reproduce the problem on any of my machines. Can you please report the settings of the various HAVE_ defines for irix? ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-04-04 14:21 Message: Logged In: YES user_id=43919 Looking over the code a bit more, I see that my last message wasn't entirely accurate. There does seem to be only one lock for both gethostbyname and gethostbyaddr (gethostbyname_lock is used for both). This is a pretty simple test that illustrates the problem I'm seeing. My previous work was on my OS X machine, but this is Python 2.2 (#3, Mar 6 2002, 18:30:37) [C] on irix6. #!/usr/bin/env python # # Copyright (c) 2002 Dustin Sallings <dustin at spy.net> # $Id$ import threading import socket import time class ResolveMe(threading.Thread): hosts=['propaganda.spy.net', 'bleu.west.spy.net', 'mail.west.spy.net'] def __init__(self): threading.Thread.__init__(self) self.setDaemon(1) def run(self): # Run 100 times for i in range(100): for h in self.hosts: nrv=socket.gethostbyname_ex(h) arv=socket.gethostbyaddr(nrv[2][0]) try: # Verify the hostname is correct assert(h==nrv[0]) # Verify the two hostnames match assert(nrv[0]==arv[0]) # Verify the two addresses match assert(nrv[2]==arv[2]) except AssertionError: print "Failed! Checking " + `h` + " got, " \ + `nrv` + " and " + `arv` if __name__=='__main__': for i in range(1,10): print "Starting " + `i` + " threads." threads=[] for n in range(i): rm=ResolveMe() rm.start() threads.append(rm) for t in threads: t.join() print `i` + " threads complete." time.sleep(60) The output looks like this: verde:/tmp 190> ./pytest.py Starting 1 threads. 1 threads complete. Starting 2 threads. Failed! Checking 'propaganda.spy.net' got, ('mail.west.spy.net', [], ['66.149.231.226']) and ('mail.west.spy.net', [], ['66.149.231.226']) Failed! Checking 'bleu.west.spy.net' got, ('mail.west.spy.net', [], ['66.149.231.226']) and ('mail.west.spy.net', [], ['66.149.231.226']) [...] ---------------------------------------------------------------------- Comment By: dustin sallings (dustin) Date: 2002-04-04 13:08 Message: Logged In: YES user_id=43919 The XMLRPC request is clearly being logged as coming from my cisco switch when it was, in fact, coming from localhost. I can't find any clear documentation, but it seems that on at least some systems gethostbyname and gethostbyaddr reference the same static variable, so having separate locks for each one (as seen in socketmodule.c) doesn't help anything. It's not so much that they're not reentrant, but you can't call any combination of the two of them at the same time. Here's some test code: #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <assert.h> int main(int argc, char **argv) { struct hostent *byaddr, *byname; unsigned int addr; struct sockaddr *sa = (struct sockaddr *)&addr; addr=1117120483; byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET); assert(byaddr); printf("byaddr: %s\n", byaddr->h_name); byname=gethostbyname("mail.west.spy.net"); assert(byname); printf("byname: %s\n", byname->h_name); printf("\nReprinting:\n\n"); printf("byaddr: %s\n", byaddr->h_name); printf("byname: %s\n", byname->h_name); } ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-04 12:06 Message: Logged In: YES user_id=21627 I'm not sure what problem you are reporting. Python does not attempt to invoke gethostbyname from two threads simultaneously; this is prevented by the GIL. On some systems, gethostname is reentrant (in the gethostname_r incarnation); Python uses that where available, and releases the GIL before calling it. So I fail to see the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470 From noreply at sourceforge.net Fri Dec 22 06:59:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 21:59:11 -0800 Subject: [ python-Feature Requests-1618676 ] Promote list comprehensions to Language Integrated Query? Message-ID: Feature Requests item #1618676, was opened at 2006-12-19 02:08 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&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: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: Promote list comprehensions to Language Integrated Query? Initial Comment: Hi, A feature idea (shall put to mailing list discussion sometime), is to extend list comprehensions to many uses of SQL or XQuery unnecessary. The benefit of language integration over passing SQL/XQuery strings to external libraries would be making code agnostic to the source of the data: in-memory tables and trees could be queried just like a relational DB or XML. An "order by" could be more efficient than sorted(f(x) for x in y). Of course list comprehensions do much of the C#-style LINQ already, but they can't (easily) do joins or "select x from a, y from b" type queries, or return XML a la XQuery. On the library side, DBAPI helps make code independent of any particular database, and sqlite in 2.5 means in-memory tables (lists of tuples) aren't really necessary. If worthwhile, implementation would probably be best suited to PyPy. C# Example from http://en.wikipedia.org/wiki/Language_Integrated_Query var q = from o in db.Orders, c in db.Customers where o.Quality == "200" && (o.CustomerID == c.CustomerID) select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName }; ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-21 21:59 Message: Logged In: YES user_id=341410 Originator: NO There have been various discussions about metasyntax proposals and Python, see the Python-3000 mailing list for references to LINQ. The general answer has been "no". Note that you can do much of what you want by overloading operations on standard Python objects like __or__, __and__, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&group_id=5470 From noreply at sourceforge.net Fri Dec 22 08:42:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 23:42:40 -0800 Subject: [ python-Bugs-411881 ] Use of "except:" in logging module Message-ID: Bugs item #411881, was opened at 2001-03-28 12:58 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&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: Python Library Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Vinay Sajip (vsajip) Summary: Use of "except:" in logging module Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-22 07:42 Message: Logged In: YES user_id=308438 Originator: NO The reason for the fair number of bare excepts in logging is this: in many cases (e.g. long-running processes like Zope servers) users don't want their application to change behaviour just because of some exception thrown in logging. So, logging aims to be very quiet indeed and swallows exceptions, except SystemExit and KeyboardInterrupt in certain situations. Also, logging is one of the modules which is (meant to be) 1.5.2 compatible, and string exceptions are not that uncommon in older code. I've looked at bare excepts in logging and here's my summary on them: logging/__init__.py: ==================== currentframe(): Backward compatibility only, sys._getframe is used where available so currentframe() will only be called on rare occasions. LogRecord.__init__(): There's a try/bare except around calls to os.path.basename() and os.path.splitext(). I could add a raise clause for SystemExit/KeyboardInterrupt. StreamHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). shutdown(): Normally only called at system exit, and will re-raise everything if raiseExceptions is set (the default). logging/handlers.py: ==================== BaseRotatingHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SocketHandler.createSocket(): I could add a raise clause for SystemExit/KeyboardInterrupt. SocketHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SysLogHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SMTPHandler.emit(): Should change bare except to ImportError for the formatdate import. Elsewhere, reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). NTEventLogHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). HTTPHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). logging/config.py: ==================== listen.ConfigStreamHandler.handle(): Reraises SystemExit and KeyboardInterrupt, prints everything else and continues - seems OK for a long-running thread. What do you think? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 14:09 Message: Logged In: YES user_id=11375 Originator: NO Raymond said (in 2003) most of the remaining except: statements looked reasonable, so I'm changing this bug's summary to refer to the logging module and reassigning to vsajip. PEP 8 doesn't say anything about bare excepts; I'll bring this up on python-dev. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-13 11:21 Message: Logged In: YES user_id=80475 Hold-off on logging for a bit. Vinay Sajip has other patches already under review. I'll ask him to fix-up the bare excepts in conjuction with those patches. For the other modules, patches are welcome. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-11 20:54 Message: Logged In: YES user_id=6380 You're right. The logging module uses more blank except: clauses than I'm comfortable with. Anyone want to upload a patch set? ---------------------------------------------------------------------- Comment By: Grant Monroe (gmonroe) Date: 2003-12-11 20:50 Message: Logged In: YES user_id=929204 A good example of an incorrect use of a blanket "except:" clause is in __init__.py in the logging module. The emit method of the StreamHandler class should special case KeyboardInterrupt. Something like this: try: .... except KeyboardInterrupt: raise except: self.handleError(record) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 02:47 Message: Logged In: YES user_id=80475 Some efforts were made to remove many bare excepts prior to Py2.3a1. Briefly scanning those that remain, it looks like many of them are appropriate or best left alone. I recommend that this bug be closed unless someone sees something specific that demands a change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 23:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-14 03:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 19:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-12 07:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-23 06:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 21:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-08-11 15:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 07:11 Message: Logged In: YES user_id=3066 Fixed modules mhlib and rfc822 (SF is having a problem generating the checkin emails, though). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-11 19:40 Message: Logged In: YES user_id=3066 OK, I've fixed up a few more modules: anydbm chunk formatter htmllib mailcap pre pty I made one change to asyncore as well, but other bare except clauses remain there; I'm not sufficiently familiar with that code to just go digging into those. I also fixed an infraction in pstats, but left others for now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-23 08:14 Message: Logged In: YES user_id=31435 Ping's intent is that pydoc work under versions of Python as early as 1.5.2, so that sys._getframe is off-limits in pydoc and its supporting code (like inspect.py). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-04-23 07:32 Message: Logged In: YES user_id=21627 For inspect.py, why is it necessary to keep the old code at all? My proposal: remove currentframe altogether, and do currentframe = sys._getframe unconditionally. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-22 14:52 Message: Logged In: YES user_id=32065 I submitted a 4th patch. I'm starting to run out of easy cases... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-04-19 09:15 Message: Logged In: YES user_id=44345 I believe the following patch is correct for the try/except in inspect.currentframe. Note that it fixes two problems. One, it avoids a bare except. Two, it gets rid of a string argument to the raise statement (string exceptions are now deprecated, right?). *** /tmp/skip/inspect.py Thu Apr 19 04:13:36 2001 --- /tmp/skip/inspect.py.~1.16~ Thu Apr 19 04:13:36 2001 *************** *** 643,650 **** def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! 1/0 ! except ZeroDivisionError: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe --- 643,650 ---- def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! raise 'catch me' ! except: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-17 15:27 Message: Logged In: YES user_id=32065 inspect.py uses sys_getframe if it's there, the other code is for backwards compatibility. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 17:24 Message: Logged In: YES user_id=6380 Actually, inspect.py should use sys._getframe()! And yes, KeyboardError is definitely one of the reasons why this is such a bad idiom... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2001-04-11 17:15 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2001-04-11 17:13 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:45 Message: Logged In: YES user_id=6380 I've applied the three patches you supplied. I agree with Martin that to do this right we'll have to tread carefully. But please go on! (No way more of this will find its way into 2.1 though.) ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-03-30 10:54 Message: Logged In: YES user_id=32065 inspect.py should be removed from this list, the use is correct. In general, I just submitted this bug so that when people are editing a module they'll notice these things, since in some cases only someone who knows the code very well can know if the "expect:" is needed or not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-03-30 06:59 Message: Logged In: YES user_id=21627 Can you identify modules where catching everything is incorrect, and propose changes to correct them. This should be done one-by-one, with careful analysis in each case, and may take well months or years to complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply at sourceforge.net Fri Dec 22 08:56:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Dec 2006 23:56:37 -0800 Subject: [ python-Bugs-1611154 ] os.path.exists("file/") failure on Solaris 9 Message-ID: Bugs item #1611154, was opened at 2006-12-07 22:25 Message generated for change (Comment added) made by eggert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611154&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists("file/") failure on Solaris 9 Initial Comment: Solaris 9 and earlier fail to conform to POSIX, in that stat("FILE/") succeeds even when FILE is not a directory. POSIX says that in this case it should fail. This problem causes os.path.exists("FILE/") to succeed when it should fail, which makes it harder to write portable Python code. One of my students ran into this problem when doing a Django-based project: his code ran fine on his Linux box, but failed when he attempted to run it on the Solaris 8 server that is the standard platform for our students. To reproduce the problem, on Solaris 8 (or 9): $ touch file $ ls -l file -rw-rw-r-- 1 eggert csfac 0 Dec 7 14:19 file $ python Python 2.5 (r25:51908, Dec 7 2006, 13:14:10) [GCC 4.1.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.exists("file/") True It should be False. I'll attach a patch that works around the problem at run-time. If you prefer something that tests for it at compile time please let me know. ---------------------------------------------------------------------- >Comment By: Paul Eggert (eggert) Date: 2006-12-22 07:56 Message: Logged In: YES user_id=17848 Originator: YES OK, I'll attach a revised patch that uses a configure test to check for this bug. File Added: python-stat-patch-2.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 13:37 Message: Logged In: YES user_id=11375 Originator: NO I think it would be sufficient to put a #ifdef ... #endif around the additional check. We don't want to make all platforms do extra system calls in order to avoid a Solaris 9 bug. Or you could write a configure test to check for this bug, but that's more complicated a task. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611154&group_id=5470 From noreply at sourceforge.net Fri Dec 22 11:25:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 02:25:24 -0800 Subject: [ python-Feature Requests-1618676 ] Promote list comprehensions to Language Integrated Query? Message-ID: Feature Requests item #1618676, was opened at 2006-12-19 12:08 Message generated for change (Comment added) made by jettlogic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&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: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: Promote list comprehensions to Language Integrated Query? Initial Comment: Hi, A feature idea (shall put to mailing list discussion sometime), is to extend list comprehensions to many uses of SQL or XQuery unnecessary. The benefit of language integration over passing SQL/XQuery strings to external libraries would be making code agnostic to the source of the data: in-memory tables and trees could be queried just like a relational DB or XML. An "order by" could be more efficient than sorted(f(x) for x in y). Of course list comprehensions do much of the C#-style LINQ already, but they can't (easily) do joins or "select x from a, y from b" type queries, or return XML a la XQuery. On the library side, DBAPI helps make code independent of any particular database, and sqlite in 2.5 means in-memory tables (lists of tuples) aren't really necessary. If worthwhile, implementation would probably be best suited to PyPy. C# Example from http://en.wikipedia.org/wiki/Language_Integrated_Query var q = from o in db.Orders, c in db.Customers where o.Quality == "200" && (o.CustomerID == c.CustomerID) select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName }; ---------------------------------------------------------------------- >Comment By: JettLogic (jettlogic) Date: 2006-12-22 12:25 Message: Logged In: YES user_id=1345991 Originator: YES Oh ok, I guess it's up to the Py3k discussions then to figure out LINQ. Funny my search for "Python Language Integrated Query" didn't turn up much (at least not the Py3k list) and now my OP is #1 on Google on 2006/12/22 for the search. Though "Python LINQ" turns up: http://sayspy.blogspot.com/2006/02/why-python-doesnt-need-something-like.html I suppose there's still the efficiency of having the database doing the filter (instead of "if x > 5") and the grouping (instead of itertools.groupby()), and the joins. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-22 07:59 Message: Logged In: YES user_id=341410 Originator: NO There have been various discussions about metasyntax proposals and Python, see the Python-3000 mailing list for references to LINQ. The general answer has been "no". Note that you can do much of what you want by overloading operations on standard Python objects like __or__, __and__, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1618676&group_id=5470 From noreply at sourceforge.net Fri Dec 22 13:52:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 04:52:26 -0800 Subject: [ python-Bugs-411881 ] Use of "except:" in logging module Message-ID: Bugs item #411881, was opened at 2001-03-28 06:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&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: Python Library Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Vinay Sajip (vsajip) Summary: Use of "except:" in logging module Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-12-22 06:52 Message: Logged In: YES user_id=44345 Originator: NO Vinay, In LogRecord.__init__ what exceptions do you expect to catch? Looking at the code for basename and splitext in os.py it's pretty hard to see how they would raise an exception unless they were passed something besides string or unicode objects. I think all you are doing here is masking programmer error. In StreamHandler.emit what might you get besides ValueError (if self.stream is closed)? I don't have time to go through each of the cases, but in general, it seems like the set of possible exceptions that could be raised at any given point in the code is generally pretty small. You should catch those exceptions and let the other stuff go. They are generally going to be programmer's errors and shouldn't be silently squashed. Skip ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-22 01:42 Message: Logged In: YES user_id=308438 Originator: NO The reason for the fair number of bare excepts in logging is this: in many cases (e.g. long-running processes like Zope servers) users don't want their application to change behaviour just because of some exception thrown in logging. So, logging aims to be very quiet indeed and swallows exceptions, except SystemExit and KeyboardInterrupt in certain situations. Also, logging is one of the modules which is (meant to be) 1.5.2 compatible, and string exceptions are not that uncommon in older code. I've looked at bare excepts in logging and here's my summary on them: logging/__init__.py: ==================== currentframe(): Backward compatibility only, sys._getframe is used where available so currentframe() will only be called on rare occasions. LogRecord.__init__(): There's a try/bare except around calls to os.path.basename() and os.path.splitext(). I could add a raise clause for SystemExit/KeyboardInterrupt. StreamHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). shutdown(): Normally only called at system exit, and will re-raise everything if raiseExceptions is set (the default). logging/handlers.py: ==================== BaseRotatingHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SocketHandler.createSocket(): I could add a raise clause for SystemExit/KeyboardInterrupt. SocketHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SysLogHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SMTPHandler.emit(): Should change bare except to ImportError for the formatdate import. Elsewhere, reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). NTEventLogHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). HTTPHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). logging/config.py: ==================== listen.ConfigStreamHandler.handle(): Reraises SystemExit and KeyboardInterrupt, prints everything else and continues - seems OK for a long-running thread. What do you think? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 08:09 Message: Logged In: YES user_id=11375 Originator: NO Raymond said (in 2003) most of the remaining except: statements looked reasonable, so I'm changing this bug's summary to refer to the logging module and reassigning to vsajip. PEP 8 doesn't say anything about bare excepts; I'll bring this up on python-dev. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-13 05:21 Message: Logged In: YES user_id=80475 Hold-off on logging for a bit. Vinay Sajip has other patches already under review. I'll ask him to fix-up the bare excepts in conjuction with those patches. For the other modules, patches are welcome. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-11 14:54 Message: Logged In: YES user_id=6380 You're right. The logging module uses more blank except: clauses than I'm comfortable with. Anyone want to upload a patch set? ---------------------------------------------------------------------- Comment By: Grant Monroe (gmonroe) Date: 2003-12-11 14:50 Message: Logged In: YES user_id=929204 A good example of an incorrect use of a blanket "except:" clause is in __init__.py in the logging module. The emit method of the StreamHandler class should special case KeyboardInterrupt. Something like this: try: .... except KeyboardInterrupt: raise except: self.handleError(record) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:47 Message: Logged In: YES user_id=80475 Some efforts were made to remove many bare excepts prior to Py2.3a1. Briefly scanning those that remain, it looks like many of them are appropriate or best left alone. I recommend that this bug be closed unless someone sees something specific that demands a change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-13 22:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 14:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-12 02:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 13:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-23 00:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 15:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-08-11 10:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 02:11 Message: Logged In: YES user_id=3066 Fixed modules mhlib and rfc822 (SF is having a problem generating the checkin emails, though). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-11 14:40 Message: Logged In: YES user_id=3066 OK, I've fixed up a few more modules: anydbm chunk formatter htmllib mailcap pre pty I made one change to asyncore as well, but other bare except clauses remain there; I'm not sufficiently familiar with that code to just go digging into those. I also fixed an infraction in pstats, but left others for now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-23 03:14 Message: Logged In: YES user_id=31435 Ping's intent is that pydoc work under versions of Python as early as 1.5.2, so that sys._getframe is off-limits in pydoc and its supporting code (like inspect.py). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-04-23 02:32 Message: Logged In: YES user_id=21627 For inspect.py, why is it necessary to keep the old code at all? My proposal: remove currentframe altogether, and do currentframe = sys._getframe unconditionally. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-22 09:52 Message: Logged In: YES user_id=32065 I submitted a 4th patch. I'm starting to run out of easy cases... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-04-19 04:15 Message: Logged In: YES user_id=44345 I believe the following patch is correct for the try/except in inspect.currentframe. Note that it fixes two problems. One, it avoids a bare except. Two, it gets rid of a string argument to the raise statement (string exceptions are now deprecated, right?). *** /tmp/skip/inspect.py Thu Apr 19 04:13:36 2001 --- /tmp/skip/inspect.py.~1.16~ Thu Apr 19 04:13:36 2001 *************** *** 643,650 **** def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! 1/0 ! except ZeroDivisionError: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe --- 643,650 ---- def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! raise 'catch me' ! except: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-17 10:27 Message: Logged In: YES user_id=32065 inspect.py uses sys_getframe if it's there, the other code is for backwards compatibility. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 12:24 Message: Logged In: YES user_id=6380 Actually, inspect.py should use sys._getframe()! And yes, KeyboardError is definitely one of the reasons why this is such a bad idiom... ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2001-04-11 12:15 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2001-04-11 12:13 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 10:45 Message: Logged In: YES user_id=6380 I've applied the three patches you supplied. I agree with Martin that to do this right we'll have to tread carefully. But please go on! (No way more of this will find its way into 2.1 though.) ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-03-30 04:54 Message: Logged In: YES user_id=32065 inspect.py should be removed from this list, the use is correct. In general, I just submitted this bug so that when people are editing a module they'll notice these things, since in some cases only someone who knows the code very well can know if the "expect:" is needed or not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-03-30 00:59 Message: Logged In: YES user_id=21627 Can you identify modules where catching everything is incorrect, and propose changes to correct them. This should be done one-by-one, with careful analysis in each case, and may take well months or years to complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:11:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:11:30 -0800 Subject: [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 14:41 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:11 Message: Logged In: YES user_id=11375 Originator: NO Was the cause of this bug ever diagnosed? Should this report remain open, or be closed? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-07-24 23:03 Message: Logged In: YES user_id=85984 This problem has cropped up again for another TMDA user, so we still have this bug in Python. In short, just as with the previous report, this user sees a 20 second delay with socket.gethostbyaddr() on a hostname which all other tools (nslookup, host, mail progs, etc) look up instantaneously. In other words, Python is the only app on his system with this problem. I had him try Python 2.3c1 to no avail. As with the previous user, he is running Linux (Redhat): Linux sparge 2.4.20-18.7 #1 Thu May 29 06:51:53 EDT 2003 i686 unknown glibc-2.2.5-43 Any other information I should provide or any diagnostics I can have the user run? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-02 23:40 Message: Logged In: YES user_id=85984 The problem was under Python 2.2. Though now the user reports that he can no longer reproduce the problem, despite not having done any Python upgrades or system configuration changes. We might just have to chuck this one up to FM (Funny Magic). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:14 Message: Logged In: YES user_id=33168 Jason, still with us? What version of python were you having the problem with? 2.1.x? 2.2.x? Do you have the problem with 2.2? Have you looked at patch #604210 (http://python.org/604210)? Can you test that? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-06 20:20 Message: Logged In: YES user_id=85984 Still having the problem, but I'm unsure how to proceed. nslookup and host both return instantly when querying datavortex.net. Only Python seems to exhibit this problem, but it still could be a system misconfiguration. This is the only time I've ever seen/heard of this behavior. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 18:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 15:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 17:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 17:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 12:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 17:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 17:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:15:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:15:01 -0800 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 13:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:15 Message: Logged In: YES user_id=11375 Originator: NO Attaching Titus' patch. File Added: python-bug737202-patch.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 14:51 Message: Logged In: YES user_id=752496 The example shows the problem in Py2.4.1. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2005-01-17 00:31 Message: Logged In: YES user_id=23486 Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS. The attached patches are just a filename; you should try downloading them to be sure they're actually a patch ;). A simpe self-contained example is at http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz it works under Python 2.2 or greater & demonstrates the problem. A patch for the current CVS HEAD is at http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff and 2.4 should probably be back-patched as well. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2005-01-16 10:11 Message: Logged In: YES user_id=376953 Encloded please find a testcase. I've checkt it with 2.3.3. Buf should still persist in 2.3.4 and 2.4. I've checked the CVS diffs and there is no change which would solve it. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:42 Message: Logged In: YES user_id=752496 Both bugs are for the same problem, keeping this alive (because it has the patch), closing the other as Duplicate. Regarding the patch, the actual code has something very similar to it, so maybe the bug is already fixed... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:42 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 01:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 09:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:28:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:28:59 -0800 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 13:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&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: Python Library >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) >Assigned to: A.M. Kuchling (akuchling) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:28 Message: Logged In: YES user_id=11375 Originator: NO Fix seems correct; applied to trunk in rev. 53139 and to 25-maint in rev. 53140. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:15 Message: Logged In: YES user_id=11375 Originator: NO Attaching Titus' patch. File Added: python-bug737202-patch.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 14:51 Message: Logged In: YES user_id=752496 The example shows the problem in Py2.4.1. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2005-01-17 00:31 Message: Logged In: YES user_id=23486 Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS. The attached patches are just a filename; you should try downloading them to be sure they're actually a patch ;). A simpe self-contained example is at http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz it works under Python 2.2 or greater & demonstrates the problem. A patch for the current CVS HEAD is at http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff and 2.4 should probably be back-patched as well. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2005-01-16 10:11 Message: Logged In: YES user_id=376953 Encloded please find a testcase. I've checkt it with 2.3.3. Buf should still persist in 2.3.4 and 2.4. I've checked the CVS diffs and there is no change which would solve it. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:42 Message: Logged In: YES user_id=752496 Both bugs are for the same problem, keeping this alive (because it has the patch), closing the other as Duplicate. Regarding the patch, the actual code has something very similar to it, so maybe the bug is already fixed... ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:42 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 01:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 09:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:33:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:33:03 -0800 Subject: [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 08:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&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: Fixed Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:33 Message: Logged In: YES user_id=11375 Originator: NO Should the suggested patch be applied, simply for the sake of consistency in test_uu? It's probably difficult to replicate this bug now; does Jack even have a MacOS 9 installation any more? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-04 09:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 07:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-04 07:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 15:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:44:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:44:08 -0800 Subject: [ python-Bugs-802128 ] Mode argument of dumbdbm does not work Message-ID: Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:50:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:50:27 -0800 Subject: [ python-Bugs-802128 ] Mode argument of dumbdbm does not work Message-ID: Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:54:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:54:44 -0800 Subject: [ python-Bugs-802128 ] Mode argument of dumbdbm does not work Message-ID: Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:54 Message: Logged In: YES user_id=3066 Originator: NO Sorry, my patch is long gone. :-( ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 From noreply at sourceforge.net Fri Dec 22 14:56:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 05:56:58 -0800 Subject: [ python-Bugs-1559142 ] some section links (previous, up, next) missing last word Message-ID: Bugs item #1559142, was opened at 2006-09-15 04:17 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Smith (thimsmith) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some section links (previous, up, next) missing last word Initial Comment: The Previous, Up and Next links in the Library Reference are often missing the last word. Examples: http://www.python.org/doc/current/lib/module-operator.html """Previous: 3.9 UserString Up: 3. Python Runtime Services Next: 3.10.1 Mapping Operators to """ (Next link missing last word "Functions".) http://www.python.org/doc/current/lib/weakref-example.html """Previous: 3.3.1 Weak Reference Objects Up: 3.3 weakref Next: 3.3.3 Weak References in """ (Next link missing last two words "Extension Types".) There are *many* examples of this. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:56 Message: Logged In: YES user_id=3066 Originator: NO This is indeed a LaTeX2HTML (mis-)feature. I think this is the first time it's been reported as a problem, but I agree that it's misleading without some indication that something was elided (an ellipsis would help a lot). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:10 Message: Logged In: YES user_id=849994 This seems to be a "feature" of LaTeX2html. It limits the links to three words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1559142&group_id=5470 From noreply at sourceforge.net Fri Dec 22 16:05:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 07:05:23 -0800 Subject: [ python-Bugs-802128 ] Mode argument of dumbdbm does not work Message-ID: Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&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: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 10:05 Message: Logged In: YES user_id=11375 Originator: NO Fix committed in rev. 53141. Leaving open while I look at umask stuff a bit. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:54 Message: Logged In: YES user_id=3066 Originator: NO Sorry, my patch is long gone. :-( ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 From noreply at sourceforge.net Fri Dec 22 16:17:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 07:17:44 -0800 Subject: [ python-Bugs-802128 ] Mode argument of dumbdbm does not work Message-ID: Bugs item #802128, was opened at 2003-09-07 16:46 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&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: Python Interpreter Core >Group: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) >Assigned to: A.M. Kuchling (akuchling) Summary: Mode argument of dumbdbm does not work Initial Comment: In dumbdbm.py 2.15, support for a mode argument was added. However, this support does not work: The mode argument is passed to __builtin__.open, which does not support specification of a mode. Instead, the third argument to that function specifies the buffer size. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 10:17 Message: Logged In: YES user_id=11375 Originator: NO Change committed for the umask stuff; I'll see how the buildbots react. Closing this bug. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 10:05 Message: Logged In: YES user_id=11375 Originator: NO Fix committed in rev. 53141. Leaving open while I look at umask stuff a bit. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-12-22 08:54 Message: Logged In: YES user_id=3066 Originator: NO Sorry, my patch is long gone. :-( ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:50 Message: Logged In: YES user_id=11375 Originator: NO Attaching my patch. File Added: dumbdbm.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:44 Message: Logged In: YES user_id=11375 Originator: NO Fred, do you still have the patch you mention? I've worked up a patch, but it must be simpler; I don't do anything with the umask. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-12 02:18 Message: Logged In: YES user_id=3066 I have what I think is a correct patch, but I should be able to simplify it (related to handling the umask). Untested on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802128&group_id=5470 From noreply at sourceforge.net Fri Dec 22 16:46:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 07:46:55 -0800 Subject: [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&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: Fixed Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) >Assigned to: A.M. Kuchling (akuchling) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2006-12-22 16:46 Message: Logged In: YES user_id=45365 Originator: YES MacOS9 is long dead, uuencoded files are probably even longer dead... If the patch looks good: apply it. But I wouldn't spend more than a few milliseconds on the whole issue:-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 14:33 Message: Logged In: YES user_id=11375 Originator: NO Should the suggested patch be applied, simply for the sake of consistency in test_uu? It's probably difficult to replicate this bug now; does Jack even have a MacOS 9 installation any more? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-04 15:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 13:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-04 13:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply at sourceforge.net Fri Dec 22 17:43:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 08:43:41 -0800 Subject: [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 08:02 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&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.6 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: A.M. Kuchling (akuchling) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 11:43 Message: Logged In: YES user_id=11375 Originator: NO Applied in rev. 53145. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-12-22 10:46 Message: Logged In: YES user_id=45365 Originator: YES MacOS9 is long dead, uuencoded files are probably even longer dead... If the patch looks good: apply it. But I wouldn't spend more than a few milliseconds on the whole issue:-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 08:33 Message: Logged In: YES user_id=11375 Originator: NO Should the suggested patch be applied, simply for the sake of consistency in test_uu? It's probably difficult to replicate this bug now; does Jack even have a MacOS 9 installation any more? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-04 09:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 07:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-04 07:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 15:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply at sourceforge.net Fri Dec 22 19:05:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 10:05:03 -0800 Subject: [ python-Bugs-1620945 ] minor inconsistency in socket.close Message-ID: Bugs item #1620945, was opened at 2006-12-22 18:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: minor inconsistency in socket.close Initial Comment: In python 2.5 socket.close, all methods are delegated to _dummy, which raises an error. It would be more consistent to delegate each method to its counterpart in _closedsocket; in particular re-closing a closed socket is not intended to raise: def close(self): self._sock.close() self._sock = _closedsocket() for method in _delegate_methods: setattr(self, method, getattr(self._sock, method)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1620945&group_id=5470 From noreply at sourceforge.net Sat Dec 23 05:03:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 20:03:22 -0800 Subject: [ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected Message-ID: Bugs item #1621111, was opened at 2006-12-23 13:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621111&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 Private: No Submitted By: Mick L (mehum) Assigned to: Jack Jansen (jackjansen) Summary: IDLE crashes on OS X 10.4 when "Preferences" selected Initial Comment: When I select 'preferences' (on IDLE 1.2, Python 2.5) or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears. Terminal reports a "Segmentation fault" upon the crash. My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable. IDLE also appears stable until I select this option. The Python crash log is attached. Please, can anyone suggest what may be causing this problem? Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621111&group_id=5470 From noreply at sourceforge.net Sat Dec 23 05:04:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Dec 2006 20:04:38 -0800 Subject: [ python-Bugs-1621111 ] IDLE crashes on OS X 10.4 when "Preferences" selected Message-ID: Bugs item #1621111, was opened at 2006-12-23 13:03 Message generated for change (Settings changed) made by mehum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621111&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 Private: No Submitted By: Mick L (mehum) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: IDLE crashes on OS X 10.4 when "Preferences" selected Initial Comment: When I select 'preferences' (on IDLE 1.2, Python 2.5) or 'Configure IDLE' (IDLE 1.1.4, Python 2.4.4 and IDLE 1.0, Python 2.3.3), Python crashes as soon as the dialog box appears. Terminal reports a "Segmentation fault" upon the crash. My system is an iMac G5 with 1 GB ram running OS X v 10.4.8, Tcl/Tk 8.4.10, and seems otherwise stable. IDLE also appears stable until I select this option. The Python crash log is attached. Please, can anyone suggest what may be causing this problem? Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621111&group_id=5470 From noreply at sourceforge.net Sat Dec 23 18:04:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Dec 2006 09:04:36 -0800 Subject: [ python-Bugs-1621367 ] random import works? Message-ID: Bugs item #1621367, was opened at 2006-12-23 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: Kentsfx2 at gmail.com Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 From noreply at sourceforge.net Sat Dec 23 19:17:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Dec 2006 10:17:39 -0800 Subject: [ python-Bugs-1257255 ] tarfile local name is local, should be abspath Message-ID: Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&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: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Blais (blais) Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile local name is local, should be abspath Initial Comment: I ran into a bug using the tarfile module with compression from a directory that did not exist anymore, and this exhibits a bug in the tarfile module. I'm not completely sure how to fix it with certainty, so instead of filing a quick patch, I submit a bug so people familiar with the module can have a look first. The problem is that when you open a tarfile with gz or bz2 compression, the TarFile object is opened with a filename that is not absolute, just local (basename is called) but the actual file is using a file-like object. Now, when you add a new entry, there is a check in the TarFile.add method that checks if we're not adding the archive itself into the tarfile, and this method calls abspath. Calling abspath on the name that has been basename'd is incorrect and a bug. It happens not to fail nor cause any problems when called from an existing directory (the test returns false), but it does not do the job it is supposed to. When the CWD has been deleted, calling abspath fails with an OSError, which brings out the problem. Some code to reproduce the bug is provided in an attachment. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2006-12-23 19:17 Message: Logged In: YES user_id=642936 Originator: NO Fixed. See patch #1262036. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-25 11:04 Message: Logged In: YES user_id=1188172 The patch has been reversed, so reopening. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-24 08:08 Message: Logged In: YES user_id=21627 This was fixed with said patch. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. ---------------------------------------------------------------------- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 From noreply at sourceforge.net Sat Dec 23 19:32:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Dec 2006 10:32:57 -0800 Subject: [ python-Bugs-1621367 ] random import works? Message-ID: Bugs item #1621367, was opened at 2006-12-23 17:04 Message generated for change (Comment added) made by dallison You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: Kentsfx2 at gmail.com Thanks ---------------------------------------------------------------------- Comment By: Dennis Allison (dallison) Date: 2006-12-23 18:32 Message: Logged In: YES user_id=31903 Originator: NO I believe the problem is with your test framework and not with random.choice(). The library function random.choice( seq ) selects, using a uniform distribution, one item from the sequence at each call. By the law of large numbers, if you have K items in the sequence, each should be returned K/N times, on average, after N calls. You should expect deviations even for fairly large N. If you want to test the randomess, use a chi-square test to test against the hypothes of uniform random selection with replacement. Of course there are many other statistical properties which ought to be checked, for example, the distribution of runs. Consider the program: import random dist = [0,0,0,0,0] for i in range(100000): j = random.choice([0,1,2,3,4]) dist[j] += 1 print dist which prints the distribution observed for each choice. With 100000 tries you'd expect each one to appear (on average) 20000 time. Running it on my a three times gives: [19839, 19871, 19996, 20035, 20259] [20043, 19870, 20025, 20109, 19953] [19947, 20033, 19970, 20111, 19939] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 From noreply at sourceforge.net Sat Dec 23 21:04:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Dec 2006 12:04:43 -0800 Subject: [ python-Bugs-1371937 ] minidom namespace problems Message-ID: Bugs item #1371937, was opened at 2005-12-02 19:47 Message generated for change (Comment added) made by paulpach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: minidom namespace problems Initial Comment: Noted on c.l.py: the minidom writexml() function doesn't tidy up namespace declarations, so you can output documents that have incorrect namespace declarations. DOM Level 3, appendix B, specifies an algorithm for normalizing namespaces; see http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html . minidom probably needs to acquire the normalizeNamespace method, and then writexml() can call it before doing its work. ---------------------------------------------------------------------- Comment By: Paul Pacheco (paulpach) Date: 2006-12-23 20:04 Message: Logged In: YES user_id=794762 Originator: NO I implemented this and uploaded a patch and test case here: http://sourceforge.net/tracker/index.php?func=detail&aid=1621421&group_id=5470&atid=305470 enjoy :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&group_id=5470 From noreply at sourceforge.net Sun Dec 24 04:20:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 23 Dec 2006 19:20:11 -0800 Subject: [ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers Message-ID: <200612240320.kBO3KBVV024486@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1612113, was opened at 2006-12-09 03:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-23 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-12-09 06:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-09 06:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 From noreply at sourceforge.net Sun Dec 24 17:27:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Dec 2006 08:27:28 -0800 Subject: [ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers Message-ID: Bugs item #1612113, was opened at 2006-12-09 06:57 Message generated for change (Comment added) made by ironfroggy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html ---------------------------------------------------------------------- >Comment By: Calvin Spealman (ironfroggy) Date: 2006-12-24 11:27 Message: Logged In: YES user_id=112166 Originator: YES This would only fail with the use of threads or weakref callbacks, most likely. I still think thats enough reason to take them back out. Assuring any order at any time, reguardless of the circumstances, I feel, is just against the concept of the dictionary. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-12-23 22:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-12-09 09:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-09 09:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 From noreply at sourceforge.net Sun Dec 24 17:30:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Dec 2006 08:30:33 -0800 Subject: [ python-Bugs-1621660 ] this module (Zen of Python) docs list broken URL Message-ID: Bugs item #1621660, was opened at 2006-12-24 11:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621660&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: this module (Zen of Python) docs list broken URL Initial Comment: The this module, the Zen of Python, has a broken (404) URL in the docs. They link to http://www.python.org/doc/current/lib/module-this.html, which does not exist. Seems like a good place to keep the text, and any links to other resources on code beauty and such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621660&group_id=5470 From noreply at sourceforge.net Mon Dec 25 16:10:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Dec 2006 07:10:25 -0800 Subject: [ python-Bugs-1622010 ] Tcl/Tk auto-expanding window Message-ID: Bugs item #1622010, was opened at 2006-12-25 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622010&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabian_M (fmareyen) Assigned to: Martin v. L?wis (loewis) Summary: Tcl/Tk auto-expanding window Initial Comment: I've experienced an auto-expanding Tcl/Tk-window: (Windows NT) import Tkinter tk = Tkinter.Tk() tk.state("zoomed") #Windows only tk.resizable(False, False) tk.mainloop() As you take the window by curser and move it slowly to the left, it expands automatically to the right. This effect doesn't exist vertically. When you use tk.state("zoomed") you needn't to set tk.resizable, but this call remained in my programm and caused that problem. Systeminformation: ------------------ Windows NT sys.api_version = 1012 #0x3f4 sys.dllhandle = 503316480 #0x1e0000 sys.getwindowsversion() -> (4, 0, 1381, 2, "Service Pack 1") sys.hexversion = 33817328 #0x20402f0 sys.platform = "win32" sys.version = "2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (I sys.version_info = (2, 4, 2, 'final', 0) sys.winver = "2.4" _tkinter.TCL_VERSION = 8.4 _tkinter.TK_VERSION = 8.4 Thanks. Fabian Mareyen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622010&group_id=5470 From noreply at sourceforge.net Tue Dec 26 04:20:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Dec 2006 19:20:11 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: <200612260320.kBQ3KBKK010573@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1605110, was opened at 2006-11-29 01:29 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&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: Python Library Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Pieter Zieschang (mad-marty) Assigned to: Vinay Sajip (vsajip) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-25 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-11 07:05 Message: Logged In: YES user_id=308438 Originator: NO I'm not sure this should be treated as a logging bug - after all, psyco is not part of standard Python and logging is only tested as a part of standard Python. Possibly this should be logged under psyco rather than Python logging. Meanwhile, if time permits I will take a look at this. ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-12-01 17:09 Message: Logged In: YES user_id=1269426 Originator: YES Hi, after some investigation, I think I found the source. Just add 'import psyco; psyco.full()' to test.py aufer imports and you get the same problem with your example. It seems, logging is not compatible with the way psyco creates proxy functions. Could be that sys._getframe returns something different. - just a guess But it works with the old logging. Is there any other information you may want ? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-11-30 01:18 Message: Logged In: YES user_id=308438 Originator: NO I need more information. For example (N.B. lines may wrap, please adjust if copy/pasting the code below): #-- test.py import module import logging logging.basicConfig(level=logging.DEBUG, format="%(relativeCreated)-6d %(module)s %(filename)s %(lineno)d - %(message)s") logging.getLogger("test").debug("Test starting, about to start thread...") threads = module.start() for t in threads: t.join() logging.getLogger("test").debug("All done.") #-- test.py ends #-- module.py import logging import threading import random import time class MyThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break class MyOtherThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break def start(): t1 = MyThread(name="Thread One") t2 = MyOtherThread(name="Thread Two") t1.start() t2.start() return t1, t2 #-- module.py ends When I run test, I get the following output: 15 test test.py 7 - Test starting, about to start thread... 15 module module.py 11 - Running in thread: Thread One 15 module module.py 22 - Running in thread: Thread Two 327 module module.py 11 - Running in thread: Thread One 343 module module.py 22 - Running in thread: Thread Two 655 module module.py 11 - Running in thread: Thread One 780 module module.py 22 - Running in thread: Thread Two 1000 module module.py 11 - Running in thread: Thread One 1546 module module.py 22 - Running in thread: Thread Two 1890 module module.py 11 - Running in thread: Thread One 2046 module module.py 11 - Running in thread: Thread One 2218 module module.py 22 - Running in thread: Thread Two 2562 module module.py 22 - Running in thread: Thread Two 3187 test test.py 11 - All done. This is the expected output. Python version used: ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 04:02 Message: Logged In: YES user_id=1269426 Originator: YES Checked again and found that the bug was introduced with Python 2.4.2. Last correctly working version is python-2.4.1.msi. ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 01:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Tue Dec 26 09:51:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 00:51:32 -0800 Subject: [ python-Bugs-1621367 ] random import works? Message-ID: Bugs item #1621367, was opened at 2006-12-23 11:04 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: Kentsfx2 at gmail.com Thanks ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 02:51 Message: Logged In: YES user_id=1591633 Originator: NO This is an issue with the way you have written your initial application. See the attachment that I've supplied to explain what is going wrong in your program. It really boils down to you adding X to each value, while X is steadily increasing in value (1, 2, 3, 4, 5). At one point, you actually add 1 to one value, and add 5 to another (for the same random choice). - Mark ---------------------------------------------------------------------- Comment By: Dennis Allison (dallison) Date: 2006-12-23 12:32 Message: Logged In: YES user_id=31903 Originator: NO I believe the problem is with your test framework and not with random.choice(). The library function random.choice( seq ) selects, using a uniform distribution, one item from the sequence at each call. By the law of large numbers, if you have K items in the sequence, each should be returned K/N times, on average, after N calls. You should expect deviations even for fairly large N. If you want to test the randomess, use a chi-square test to test against the hypothes of uniform random selection with replacement. Of course there are many other statistical properties which ought to be checked, for example, the distribution of runs. Consider the program: import random dist = [0,0,0,0,0] for i in range(100000): j = random.choice([0,1,2,3,4]) dist[j] += 1 print dist which prints the distribution observed for each choice. With 100000 tries you'd expect each one to appear (on average) 20000 time. Running it on my a three times gives: [19839, 19871, 19996, 20035, 20259] [20043, 19870, 20025, 20109, 19953] [19947, 20033, 19970, 20111, 19939] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 From noreply at sourceforge.net Tue Dec 26 09:54:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 00:54:26 -0800 Subject: [ python-Bugs-1621367 ] random import works? Message-ID: Bugs item #1621367, was opened at 2006-12-23 11:04 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: Kentsfx2 at gmail.com Thanks ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 02:54 Message: Logged In: YES user_id=1591633 Originator: NO Sorry, it appears that I can't upload a file, or I'm missing the button. Anyway, you can find the file you're lookign for here: http://www.pandapocket.com/python/rand2.pys ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 02:51 Message: Logged In: YES user_id=1591633 Originator: NO This is an issue with the way you have written your initial application. See the attachment that I've supplied to explain what is going wrong in your program. It really boils down to you adding X to each value, while X is steadily increasing in value (1, 2, 3, 4, 5). At one point, you actually add 1 to one value, and add 5 to another (for the same random choice). - Mark ---------------------------------------------------------------------- Comment By: Dennis Allison (dallison) Date: 2006-12-23 12:32 Message: Logged In: YES user_id=31903 Originator: NO I believe the problem is with your test framework and not with random.choice(). The library function random.choice( seq ) selects, using a uniform distribution, one item from the sequence at each call. By the law of large numbers, if you have K items in the sequence, each should be returned K/N times, on average, after N calls. You should expect deviations even for fairly large N. If you want to test the randomess, use a chi-square test to test against the hypothes of uniform random selection with replacement. Of course there are many other statistical properties which ought to be checked, for example, the distribution of runs. Consider the program: import random dist = [0,0,0,0,0] for i in range(100000): j = random.choice([0,1,2,3,4]) dist[j] += 1 print dist which prints the distribution observed for each choice. With 100000 tries you'd expect each one to appear (on average) 20000 time. Running it on my a three times gives: [19839, 19871, 19996, 20035, 20259] [20043, 19870, 20025, 20109, 19953] [19947, 20033, 19970, 20111, 19939] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 From noreply at sourceforge.net Tue Dec 26 10:24:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 01:24:40 -0800 Subject: [ python-Bugs-1619659 ] htonl, ntohl don't handle negative longs Message-ID: Bugs item #1619659, was opened at 2006-12-20 12:42 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: htonl, ntohl don't handle negative longs Initial Comment: >>> htonl(-5) -67108865 >>> htonl(-5L) Traceback (most recent call last): File "", line 1, in ? OverflowError: can't convert negative value to unsigned long It works fine in 2.1 and 2.2, but fails in 2.3, 2.4, 2.5. htons, ntohs do not appear to have the bug, but I'm not 100% sure. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 03:24 Message: Logged In: YES user_id=1591633 Originator: NO >From man page for htonl and friends: #include uint32_t htonl(uint32_t hostlong); uint16_t htons(uint16_t hostshort); uint32_t ntohl(uint32_t netlong); uint16_t ntohs(uint16_t netshort); Python does call these underlying functions in Modules/socketmodule.c. The problem comes from that PyLong_AsUnsignedLong() called in socket_htonl() specifically checks to see that the value cannot be less than 0. The error checking was rather exquisite, I might add. - Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470 From noreply at sourceforge.net Tue Dec 26 18:47:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 09:47:22 -0800 Subject: [ python-Bugs-1622533 ] null bytes in docstrings Message-ID: Bugs item #1622533, was opened at 2006-12-26 18:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622533&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: null bytes in docstrings Initial Comment: the following docstrings contain bogus control characters: module difflib, function _mdiff, contains four invalid bytes: ['\x00', '\x00', '\x00', '\x01'] module StringIO, method readline, contains a null byte: ['\x00'] since this breaks help() and probably a bunch of other documentation tools, it would probably be a good idea to add the missing backslashes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622533&group_id=5470 From noreply at sourceforge.net Tue Dec 26 19:27:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 10:27:34 -0800 Subject: [ python-Bugs-1622533 ] null bytes in docstrings Message-ID: Bugs item #1622533, was opened at 2006-12-26 12:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622533&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: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: null bytes in docstrings Initial Comment: the following docstrings contain bogus control characters: module difflib, function _mdiff, contains four invalid bytes: ['\x00', '\x00', '\x00', '\x01'] module StringIO, method readline, contains a null byte: ['\x00'] since this breaks help() and probably a bunch of other documentation tools, it would probably be a good idea to add the missing backslashes... ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-26 13:27 Message: Logged In: YES user_id=80475 Originator: NO Clearer and simpler to make the whole docstring raw. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622533&group_id=5470 From noreply at sourceforge.net Tue Dec 26 19:28:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 10:28:14 -0800 Subject: [ python-Bugs-1621367 ] random import works? Message-ID: Bugs item #1621367, was opened at 2006-12-23 12:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: Kentsfx2 at gmail.com Thanks ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 03:54 Message: Logged In: YES user_id=1591633 Originator: NO Sorry, it appears that I can't upload a file, or I'm missing the button. Anyway, you can find the file you're lookign for here: http://www.pandapocket.com/python/rand2.pys ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 03:51 Message: Logged In: YES user_id=1591633 Originator: NO This is an issue with the way you have written your initial application. See the attachment that I've supplied to explain what is going wrong in your program. It really boils down to you adding X to each value, while X is steadily increasing in value (1, 2, 3, 4, 5). At one point, you actually add 1 to one value, and add 5 to another (for the same random choice). - Mark ---------------------------------------------------------------------- Comment By: Dennis Allison (dallison) Date: 2006-12-23 13:32 Message: Logged In: YES user_id=31903 Originator: NO I believe the problem is with your test framework and not with random.choice(). The library function random.choice( seq ) selects, using a uniform distribution, one item from the sequence at each call. By the law of large numbers, if you have K items in the sequence, each should be returned K/N times, on average, after N calls. You should expect deviations even for fairly large N. If you want to test the randomess, use a chi-square test to test against the hypothes of uniform random selection with replacement. Of course there are many other statistical properties which ought to be checked, for example, the distribution of runs. Consider the program: import random dist = [0,0,0,0,0] for i in range(100000): j = random.choice([0,1,2,3,4]) dist[j] += 1 print dist which prints the distribution observed for each choice. With 100000 tries you'd expect each one to appear (on average) 20000 time. Running it on my a three times gives: [19839, 19871, 19996, 20035, 20259] [20043, 19870, 20025, 20109, 19953] [19947, 20033, 19970, 20111, 19939] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 From noreply at sourceforge.net Tue Dec 26 19:40:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 10:40:27 -0800 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 04:49 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Python Library Group: Python 2.5 Status: Open Resolution: Later Priority: 7 Private: No Submitted By: V?clav Haisman (wilx) >Assigned to: Neal Norwitz (nnorwitz) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-29 02:35 Message: Logged In: YES user_id=34209 Not unless you want another release candidate. copy.deepcopy has never worked on array instances, so it's not a release-preventing bug (but each bugfix may *add* a release-preventing bug by accident :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:32 Message: Logged In: YES user_id=80475 Should this be fixed in the release candidate? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-24 13:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Wed Dec 27 02:15:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Dec 2006 17:15:39 -0800 Subject: [ python-Bugs-1622664 ] language reference index links are broken Message-ID: Bugs item #1622664, was opened at 2006-12-26 16:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: language reference index links are broken Initial Comment: http://docs.python.org/ref/genindex.html For example, this text "globals() (built-in function)" links to http://docs.python.org/ref/exec.html#l2h-571, which is completely wrong. Some links are correct, but many others are broken. The page footer says "Release 2.5, documentation updated on 19th September, 2006." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&group_id=5470 From noreply at sourceforge.net Wed Dec 27 11:39:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Dec 2006 02:39:50 -0800 Subject: [ python-Bugs-1496501 ] tarfile.py: dict order dependency Message-ID: Bugs item #1496501, was opened at 2006-05-28 20:42 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Python Library Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile.py: dict order dependency Initial Comment: When guessing the type of a file, tarfile.py tries to open it in .tar, .tar.gz and .tar.bz2 modes successfully. The problem is that in conjunction with a fileobj argument, failed attempts can advance the current position of the fileobj, and cause the following attempts to fail as well. This didn't show up so far because, by chance, the order in which the OPEN_METH dictionary is enumerated is somehow the "correct" one. The problem can be seen by changing this order and re-running test_tarfile.py; for example, reverse the order (tarfile.py line 1013): for comptype in reversed(cls.OPEN_METH): ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2006-12-27 11:39 Message: Logged In: YES user_id=642936 Originator: NO Fixed with said patch. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 19:46 Message: Logged In: YES user_id=591932 added patch 1504073 because SF won't let just anyone attach files to bugs. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 18:15 Message: Logged In: YES user_id=591932 The invidual openers could tell() the fileobj and revert with a seek() on failure. The module requires those methods be implemented already to work so that is safe. I'll cook up a patch. But basically open() isn't as extensible as it seems. Stream reading and writing isn't supported for injected compression types and appending only works on plain tarfiles. I'm guessing that isn't a problem in practice or someone would have mentioned it by now ;) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-10 12:46 Message: Logged In: YES user_id=4771 If possible, I would prefer that the constructors were fixed to become order-independent. Not sure how easy this is, though. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 21:56 Message: Logged In: YES user_id=591932 I took a look at tarfile.py and though there is this comment about OPEN_METH # This concept allows one to subclass TarFile without losing the comfort of # the super-constructor. A sub-constructor is registered and made available # by adding it to the mapping in OPEN_METH. because adding items to OPEN_METH could change the order and break the Tarfile.open() classmethod I doubt adding to OPEN_METH is done in practice. +1 for renaming OPEN_METH to _OPEN_METH and making it a list of two-tuples. +0 on changing the two tups from ('typename', 'funcname') to ('typename', function_ref) and dropping the getattr functionality. The three default openers are not listed in the public interface so if anyone is subclassing Tarfile and overriding them (doubtful) they are doing so at their own peril. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&group_id=5470 From noreply at sourceforge.net Wed Dec 27 14:26:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Dec 2006 05:26:07 -0800 Subject: [ python-Bugs-1622896 ] Exception when compressing certain data with bz2 Message-ID: Bugs item #1622896, was opened at 2006-12-27 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Gontmakher (gsasha) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when compressing certain data with bz2 Initial Comment: Looks like an out-of-bounds array access... might be a security problem. The attached file includes a script which, when executed, tries to pack the two given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu Edgy), the program fails with the following exception: -------------------- Traceback (most recent call last): File "test.py", line 13, in ? block = compressor.compress(open("compress-0067/"+file, "rb").read()) ValueError: the bz2 library has received wrong parameters -------------------- The problem occurs under either python2.4 or 2.5 (I don't have other versions to test with). Sorry, the file is large... I tried to reduce the example to smaller number of files etc., but no such luck. The file is too large to be submitted here as an attachment, so I have uploaded it to http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 From noreply at sourceforge.net Wed Dec 27 18:46:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Dec 2006 09:46:24 -0800 Subject: [ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows Message-ID: Bugs item #1568240, was opened at 2006-09-30 12:19 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&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: 7 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. L?wis (loewis) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2006-12-27 19:46 Message: Logged In: YES user_id=539787 Originator: YES Should we bump the bug up and/or assign it to Neal Norwitz as he requested on Python-Dev? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 From noreply at sourceforge.net Wed Dec 27 22:18:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Dec 2006 13:18:45 -0800 Subject: [ python-Bugs-1623153 ] preferred diff format should be mentioned as "unified". Message-ID: Bugs item #1623153, was opened at 2006-12-27 16:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: preferred diff format should be mentioned as "unified". Initial Comment: The page at http://www.python.org/dev/tools/ mentions that context diffs are preferred. However, the link at http://www.python.org/dev/patches/ mentions that "We like unified diffs. We grudgingly accept contextual diffs.". So "tools" page should preferably mention unified diffs as well. Thanks, Raghu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&group_id=5470 From noreply at sourceforge.net Thu Dec 28 08:59:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Dec 2006 23:59:34 -0800 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 02:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Python Library Group: Python 2.5 Status: Open >Resolution: Accepted >Priority: 9 Private: No Submitted By: V?clav Haisman (wilx) Assigned to: Neal Norwitz (nnorwitz) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-27 23:59 Message: Logged In: YES user_id=33168 Originator: NO Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing it was just forgotten. I don't see any mention in Misc/NEWS either. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-29 00:35 Message: Logged In: YES user_id=34209 Not unless you want another release candidate. copy.deepcopy has never worked on array instances, so it's not a release-preventing bug (but each bugfix may *add* a release-preventing bug by accident :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 06:32 Message: Logged In: YES user_id=80475 Should this be fixed in the release candidate? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-24 11:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Thu Dec 28 09:27:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 00:27:36 -0800 Subject: [ python-Bugs-1622896 ] Exception when compressing certain data with bz2 Message-ID: Bugs item #1622896, was opened at 2006-12-27 05:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Gontmakher (gsasha) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when compressing certain data with bz2 Initial Comment: Looks like an out-of-bounds array access... might be a security problem. The attached file includes a script which, when executed, tries to pack the two given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu Edgy), the program fails with the following exception: -------------------- Traceback (most recent call last): File "test.py", line 13, in ? block = compressor.compress(open("compress-0067/"+file, "rb").read()) ValueError: the bz2 library has received wrong parameters -------------------- The problem occurs under either python2.4 or 2.5 (I don't have other versions to test with). Sorry, the file is large... I tried to reduce the example to smaller number of files etc., but no such luck. The file is too large to be submitted here as an attachment, so I have uploaded it to http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 00:27 Message: Logged In: YES user_id=33168 Originator: NO I don't understand why you think this is an array out of bounds. I ran your test case under valgrind and it reported no problems. I can reproduce the problem. I have attached a patch that fixes the problem for me. I am not certain it's the correct fix however. The unit tests pass with this modification. File Added: bz2.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 From noreply at sourceforge.net Thu Dec 28 10:11:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 01:11:59 -0800 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 11:49 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Python Library Group: Python 2.5 Status: Open Resolution: Accepted Priority: 9 Private: No Submitted By: V?clav Haisman (wilx) >Assigned to: Thomas Wouters (twouters) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-12-28 10:11 Message: Logged In: YES user_id=34209 Originator: NO The 2.5 branch at the time was still pre-2.5.0, and we didn't want to make this change between release candidate and release. It's safe to be checked into release25-maint now. I'll do it sometime tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 08:59 Message: Logged In: YES user_id=33168 Originator: NO Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing it was just forgotten. I don't see any mention in Misc/NEWS either. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-29 09:35 Message: Logged In: YES user_id=34209 Not unless you want another release candidate. copy.deepcopy has never worked on array instances, so it's not a release-preventing bug (but each bugfix may *add* a release-preventing bug by accident :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 15:32 Message: Logged In: YES user_id=80475 Should this be fixed in the release candidate? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-24 20:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Thu Dec 28 10:17:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 01:17:48 -0800 Subject: [ python-Bugs-1622896 ] Exception when compressing certain data with bz2 Message-ID: Bugs item #1622896, was opened at 2006-12-27 15:26 Message generated for change (Comment added) made by gsasha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Gontmakher (gsasha) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when compressing certain data with bz2 Initial Comment: Looks like an out-of-bounds array access... might be a security problem. The attached file includes a script which, when executed, tries to pack the two given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu Edgy), the program fails with the following exception: -------------------- Traceback (most recent call last): File "test.py", line 13, in ? block = compressor.compress(open("compress-0067/"+file, "rb").read()) ValueError: the bz2 library has received wrong parameters -------------------- The problem occurs under either python2.4 or 2.5 (I don't have other versions to test with). Sorry, the file is large... I tried to reduce the example to smaller number of files etc., but no such luck. The file is too large to be submitted here as an attachment, so I have uploaded it to http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2 ---------------------------------------------------------------------- >Comment By: Alex Gontmakher (gsasha) Date: 2006-12-28 11:17 Message: Logged In: YES user_id=47707 Originator: YES I saw that the effect occurs only when one compressor finishes and is destroyed, and then the second one gives the "wrong parameters". Usually, for such an effect to happen, the first compressor must have some permanent effect on the system - and since it was destroyed before the second one was created, it was only natural to assume that the reason was an out of bounds access. My approach is that such a bug should be suspected as an out-of-bounds access until shown othervise, especially in a language like Python where it is natural to assume that such problems shouldn't occur and that it is safe to use security-wise. Of course I'll be happy to learn that it's just a simple bug. On a related note, will the fix be backported to all the relevant Python versions? If you understand why the bug happens (I don't, sorry, have no idea of internals of Python), you might be able to generate a compact test case that would capture the erroneous behavior. Best regards, Alex ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 10:27 Message: Logged In: YES user_id=33168 Originator: NO I don't understand why you think this is an array out of bounds. I ran your test case under valgrind and it reported no problems. I can reproduce the problem. I have attached a patch that fixes the problem for me. I am not certain it's the correct fix however. The unit tests pass with this modification. File Added: bz2.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 From noreply at sourceforge.net Thu Dec 28 22:37:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 13:37:46 -0800 Subject: [ python-Bugs-1619659 ] htonl, ntohl don't handle negative longs Message-ID: Bugs item #1619659, was opened at 2006-12-20 11:42 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: htonl, ntohl don't handle negative longs Initial Comment: >>> htonl(-5) -67108865 >>> htonl(-5L) Traceback (most recent call last): File "", line 1, in ? OverflowError: can't convert negative value to unsigned long It works fine in 2.1 and 2.2, but fails in 2.3, 2.4, 2.5. htons, ntohs do not appear to have the bug, but I'm not 100% sure. ---------------------------------------------------------------------- >Comment By: Adam Olsen (rhamphoryncus) Date: 2006-12-28 14:37 Message: Logged In: YES user_id=12364 Originator: YES I forgot to mention it, but the only reason htonl should get passed a negative number is that it (and possibly struct?) produce a negative number. Changing them to always produce positive numbers may be an alternative solution. Or we may want to do both, always producing positive while also accepting negative. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 02:24 Message: Logged In: YES user_id=1591633 Originator: NO >From man page for htonl and friends: #include uint32_t htonl(uint32_t hostlong); uint16_t htons(uint16_t hostshort); uint32_t ntohl(uint32_t netlong); uint16_t ntohs(uint16_t netshort); Python does call these underlying functions in Modules/socketmodule.c. The problem comes from that PyLong_AsUnsignedLong() called in socket_htonl() specifically checks to see that the value cannot be less than 0. The error checking was rather exquisite, I might add. - Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470 From noreply at sourceforge.net Thu Dec 28 22:49:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 13:49:31 -0800 Subject: [ python-Bugs-1623890 ] module docstring for subprocess is wrong Message-ID: Bugs item #1623890, was opened at 2006-12-28 13:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623890&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: module docstring for subprocess is wrong Initial Comment: The module docstring for subprocess is wrong. It says: communicate(input=None) Interact with process: Send data to stdin. Read data from stdout and stderr, until end-of-file is reached. Wait for process to terminate. The optional stdin argument should be a string to be sent to the child process, or None, if no data should be sent to the child. I'm not sure how to word the first stdin, but the second one should definitely be input, not stdin. Also need to verify the docstring for the communicate method. I'm guessing this affects Python 2.4 and later. Looking at 2.4.1? right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623890&group_id=5470 From noreply at sourceforge.net Fri Dec 29 02:29:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 17:29:25 -0800 Subject: [ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory Message-ID: Bugs item #1565525, was opened at 2006-09-26 06:58 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2006-12-29 01:29 Message: Logged In: YES user_id=731668 Originator: YES > If you are saying that it is unavoidable in your > application: I have difficulties believing this. For > example, you could do > > s.e = sys.exc_info()[:2] > > This would drop the traceback, and thus not create a cyclic > reference. Since, in the program you present, the traceback > is never used, this looks like a "legal" simplification (of > course, you don't use s.e at all in this program, so I can > only guess that you don't need the traceback in your real > application). "This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform." I would like the traceback object so that I can re-raise the error. I can stringify it as tim_one suggests, but that can't be used with 'raise' and 'try','except' later. It is not important for my application to have all the references that the traceback object contains, which is what is causing the massive memory requirement. If I could replace the exc_info()[2] with a traceback look-alike that only held file, line, etc information for printing a standard traceback, that would solve this problem. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-26 20:48 Message: Logged In: YES user_id=11375 A quick grep of the stdlib turns up various uses of sys.exc_info that do put it in a local variable., e.g. doctest._exception_traceback, unittest._exc_info_to_string, SimpleXMLRPCServer._marshaled_dispatch. Do these all need to be fixed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-28 03:48 Message: Logged In: YES user_id=31435 [Martin] > tim_one: Why do you think your proposed modification of > introducing get_traceback would help? The frame foo still > refers to s (which is an O), and s.e will still refer > to the traceback that includes foo. Sorry about that! It was an illusion, of course. I wanted to suggest a quick fix, and "tested it" too hastily in a program that didn't actually bloat with /or/ without it. For the OP, I had need last year of capturing a traceback and (possibly) displaying it later in ZODB. It never would have occurred to me to try saving away exc_info(), though. Instead I used the `traceback` module to capture the traceback output (a string), which was (possibly) displayed later, with annotations, by a different thread. No cycles, no problems. BTW, I must repeat that there is no simple-minded way to 'repair' this. That isn't based on general principle, but on knowledge of how Python is implemented. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 03:03 Message: Logged In: YES user_id=21627 I disagree that the circular reference is non-obvious. I'm not sure what your application is, but I would expect that callers of sys.exc_info should be fully aware what a traceback is, and how it refers to the current frames. I do agree that it is unavoidable; I fail to see that it is a bug because of that (something unavoidable cannot be a bug). If you are saying that it is unavoidable in your application: I have difficulties believing this. For example, you could do s.e = sys.exc_info()[:2] This would drop the traceback, and thus not create a cyclic reference. Since, in the program you present, the traceback is never used, this looks like a "legal" simplification (of course, you don't use s.e at all in this program, so I can only guess that you don't need the traceback in your real application). As for the time of cleanup not being controllable: you can certainly control frequency of gc with gc.set_threshold; no need to invoke gc explicitly. tim_one: Why do you think your proposed modification of introducing get_traceback would help? The frame foo still refers to s (which is an O), and s.e will still refer to the traceback that includes foo. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 21:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-27 07:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 03:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-26 10:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(100000) line. Python has no problem collecting the cyclic trash, but you're creating 100000 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add this method to your class O: def get_traceback(self): self.e = sys.exc_info() and inside foo() invoke: s.get_traceback() instead of doing: s.e = sys.exc_info() Is that unreasonable? Perhaps simpler is to define a function like: def get_exc_info(): return sys.exc_info() and inside foo() do: s.e = get_exc_info() No cyclic trash gets created that way either. These are the kinds of things the manual has suggested doing for the last 10 years ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&group_id=5470 From noreply at sourceforge.net Fri Dec 29 04:02:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 19:02:09 -0800 Subject: [ python-Bugs-1623890 ] module docstring for subprocess is wrong Message-ID: Bugs item #1623890, was opened at 2006-12-28 13:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623890&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: Python Library >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: module docstring for subprocess is wrong Initial Comment: The module docstring for subprocess is wrong. It says: communicate(input=None) Interact with process: Send data to stdin. Read data from stdout and stderr, until end-of-file is reached. Wait for process to terminate. The optional stdin argument should be a string to be sent to the child process, or None, if no data should be sent to the child. I'm not sure how to word the first stdin, but the second one should definitely be input, not stdin. Also need to verify the docstring for the communicate method. I'm guessing this affects Python 2.4 and later. Looking at 2.4.1? right now. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 19:02 Message: Logged In: YES user_id=33168 Originator: YES Committed revision 53187. (2.5) Committed revision 53188. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623890&group_id=5470 From noreply at sourceforge.net Fri Dec 29 08:38:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Dec 2006 23:38:05 -0800 Subject: [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 11:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&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: Python Library Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 23:38 Message: Logged In: YES user_id=33168 Originator: NO Not fully diagnosed, no. I suspect (based on reading the comments here) that the other programs didn't use the threaded version where python did. That's the only reasonable explanation I can come up with. I'm closing this since we could never reproduce. I don't recall ever seeing another similar bug report. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 05:11 Message: Logged In: YES user_id=11375 Originator: NO Was the cause of this bug ever diagnosed? Should this report remain open, or be closed? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-07-24 20:03 Message: Logged In: YES user_id=85984 This problem has cropped up again for another TMDA user, so we still have this bug in Python. In short, just as with the previous report, this user sees a 20 second delay with socket.gethostbyaddr() on a hostname which all other tools (nslookup, host, mail progs, etc) look up instantaneously. In other words, Python is the only app on his system with this problem. I had him try Python 2.3c1 to no avail. As with the previous user, he is running Linux (Redhat): Linux sparge 2.4.20-18.7 #1 Thu May 29 06:51:53 EDT 2003 i686 unknown glibc-2.2.5-43 Any other information I should provide or any diagnostics I can have the user run? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-02 20:40 Message: Logged In: YES user_id=85984 The problem was under Python 2.2. Though now the user reports that he can no longer reproduce the problem, despite not having done any Python upgrades or system configuration changes. We might just have to chuck this one up to FM (Funny Magic). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 13:14 Message: Logged In: YES user_id=33168 Jason, still with us? What version of python were you having the problem with? 2.1.x? 2.2.x? Do you have the problem with 2.2? Have you looked at patch #604210 (http://python.org/604210)? Can you test that? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-06 17:20 Message: Logged In: YES user_id=85984 Still having the problem, but I'm unsure how to proceed. nslookup and host both return instantly when querying datavortex.net. Only Python seems to exhibit this problem, but it still could be a system misconfiguration. This is the only time I've ever seen/heard of this behavior. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 15:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 15:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 12:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 14:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 14:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 09:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 14:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 14:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply at sourceforge.net Fri Dec 29 16:05:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 07:05:58 -0800 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 11:49 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: V?clav Haisman (wilx) Assigned to: Thomas Wouters (twouters) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-12-29 16:05 Message: Logged In: YES user_id=34209 Originator: NO Backported. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-12-28 10:11 Message: Logged In: YES user_id=34209 Originator: NO The 2.5 branch at the time was still pre-2.5.0, and we didn't want to make this change between release candidate and release. It's safe to be checked into release25-maint now. I'll do it sometime tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 08:59 Message: Logged In: YES user_id=33168 Originator: NO Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing it was just forgotten. I don't see any mention in Misc/NEWS either. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-29 09:35 Message: Logged In: YES user_id=34209 Not unless you want another release candidate. copy.deepcopy has never worked on array instances, so it's not a release-preventing bug (but each bugfix may *add* a release-preventing bug by accident :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 15:32 Message: Logged In: YES user_id=80475 Should this be fixed in the release candidate? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-24 20:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Fri Dec 29 19:35:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 10:35:20 -0800 Subject: [ python-Bugs-1624534 ] updating a set in a list of sets will update all of them Message-ID: Bugs item #1624534, was opened at 2006-12-29 22:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Amir Reza Khosroshahi (amir_reza) Assigned to: Nobody/Anonymous (nobody) Summary: updating a set in a list of sets will update all of them Initial Comment: If you make a list of sets in this way: l = [set()] * 10 And then update one of them, by another set, say y: y = set([1,2,3]) l[0] |= y Then all of the elements of l, that is, all the sets in l will be updated. But if you use a direct union: l[0] = l[0] | y This will not happen. You should define the list that way (using the * operator) in order for this situation to take place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&group_id=5470 From noreply at sourceforge.net Fri Dec 29 20:46:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 11:46:50 -0800 Subject: [ python-Bugs-1624534 ] updating a set in a list of sets will update all of them Message-ID: Bugs item #1624534, was opened at 2006-12-29 22:05 Message generated for change (Comment added) made by amir_reza You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&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: Python Library Group: Python 2.5 >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Amir Reza Khosroshahi (amir_reza) Assigned to: Nobody/Anonymous (nobody) Summary: updating a set in a list of sets will update all of them Initial Comment: If you make a list of sets in this way: l = [set()] * 10 And then update one of them, by another set, say y: y = set([1,2,3]) l[0] |= y Then all of the elements of l, that is, all the sets in l will be updated. But if you use a direct union: l[0] = l[0] | y This will not happen. You should define the list that way (using the * operator) in order for this situation to take place. ---------------------------------------------------------------------- >Comment By: Amir Reza Khosroshahi (amir_reza) Date: 2006-12-29 23:16 Message: Logged In: YES user_id=1470587 Originator: YES Sorry! It is a feature, not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624534&group_id=5470 From noreply at sourceforge.net Fri Dec 29 23:03:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 14:03:29 -0800 Subject: [ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers Message-ID: Bugs item #1612113, was opened at 2006-12-09 12:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-29 23:03 Message: Logged In: YES user_id=21627 Originator: NO It can't fail just because of the presence of threads or weakref callbacks, unless these perform modifications to the dictionary. Such modifications can, of course, also happen in a regular loop, if the code in the loop performs the modification (either directly or indirectly, through function calls). As Tim says: if it hurts your feelings to make such an assumption, then just don't make it for yourself (i.e. don't rely on it in your own programs). ---------------------------------------------------------------------- Comment By: Calvin Spealman (ironfroggy) Date: 2006-12-24 17:27 Message: Logged In: YES user_id=112166 Originator: YES This would only fail with the use of threads or weakref callbacks, most likely. I still think thats enough reason to take them back out. Assuring any order at any time, reguardless of the circumstances, I feel, is just against the concept of the dictionary. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-12-24 04:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-12-09 15:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-09 15:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 From noreply at sourceforge.net Fri Dec 29 23:26:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 14:26:27 -0800 Subject: [ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows Message-ID: Bugs item #1568240, was opened at 2006-09-30 11:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&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: 7 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. L?wis (loewis) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-12-29 23:26 Message: Logged In: YES user_id=21627 Originator: NO I haven't read Neal's message yet, but I wonder what he could do about it. I plan to fix this with 2.5.1, there is absolutely no way to fix this earlier. I'm not sure who "we" is who would like to bump the bug, and what precisely this bumping would do; tzot, please refrain from changing the priority to higher than 7. These priorities are reserved to the release manager. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2006-12-27 18:46 Message: Logged In: YES user_id=539787 Originator: YES Should we bump the bug up and/or assign it to Neal Norwitz as he requested on Python-Dev? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 From noreply at sourceforge.net Sat Dec 30 01:03:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 16:03:18 -0800 Subject: [ python-Bugs-1624674 ] webbrowser.open_new() suggestion Message-ID: Bugs item #1624674, was opened at 2006-12-30 01:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624674&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: Imre P?ntek (imi1984) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open_new() suggestion Initial Comment: Hello, under Linux if I use webbrowser.open_new('...') a konqueror gets invoked. At the time when invoking konqueror (maybe you probe first, but anyways) you assume that user has a properly installed kde. But if you assume the user has a properly installed KDE you have a better opportunity to open a webpage, even in the browser preferred by the user -- no matter really what it is. Try this one: kfmclient exec http://sourceforge.net/ using this one the client associated with .html in kcontrol gets invoked. I suppose that (becouse of the ability to customize the browser) this way would be better if available than guessing which browser would the user prefer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1624674&group_id=5470 From noreply at sourceforge.net Sat Dec 30 03:15:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 18:15:27 -0800 Subject: [ python-Bugs-1619659 ] htonl, ntohl don't handle negative longs Message-ID: Bugs item #1619659, was opened at 2006-12-20 12:42 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: htonl, ntohl don't handle negative longs Initial Comment: >>> htonl(-5) -67108865 >>> htonl(-5L) Traceback (most recent call last): File "", line 1, in ? OverflowError: can't convert negative value to unsigned long It works fine in 2.1 and 2.2, but fails in 2.3, 2.4, 2.5. htons, ntohs do not appear to have the bug, but I'm not 100% sure. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-29 20:15 Message: Logged In: YES user_id=1591633 Originator: NO Hmmm, yes, I see a problem. At the very least, I think we may be wanting some consistency between the acceptance of ints and longs. Also, I think we should return an unsigned long instead of just a long (which can be negative). I've got a patch right now to make htonl, ntohl, htons, and ntohs never return a negative number. I'm rather waffling to the idea of whether we should accept negative numbers at all in any of the functions. The behavior is undefined, and it is, afterall, better not to guess what a user intended. However, consistency should be a desirable goal, and we should accept make the interface consistent for both ints and longs. Mark ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-12-28 15:37 Message: Logged In: YES user_id=12364 Originator: YES I forgot to mention it, but the only reason htonl should get passed a negative number is that it (and possibly struct?) produce a negative number. Changing them to always produce positive numbers may be an alternative solution. Or we may want to do both, always producing positive while also accepting negative. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-26 03:24 Message: Logged In: YES user_id=1591633 Originator: NO >From man page for htonl and friends: #include uint32_t htonl(uint32_t hostlong); uint16_t htons(uint16_t hostshort); uint32_t ntohl(uint32_t netlong); uint16_t ntohs(uint16_t netshort); Python does call these underlying functions in Modules/socketmodule.c. The problem comes from that PyLong_AsUnsignedLong() called in socket_htonl() specifically checks to see that the value cannot be less than 0. The error checking was rather exquisite, I might add. - Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470 From noreply at sourceforge.net Sat Dec 30 04:20:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 19:20:18 -0800 Subject: [ python-Bugs-1599931 ] Immediate Crash on Open Message-ID: <200612300320.kBU3KI58012247@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1599931, was opened at 2006-11-20 11:45 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&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: Python 2.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Farhymn (farhymn) Assigned to: Kurt B. Kaiser (kbk) Summary: Immediate Crash on Open Initial Comment: Python 2.5 IDLE crashes -immediately- upon open, leaving enough time to hold down the enter button on the executable and only have the pythonw process show up one-at-a-time. This is version specific, as 2.4 Final worked fine. Now all applications cannot run. I made sure to uninstall 2.4 before installing 2.5, so it isn't a version conflict (as far as I can tell). Running Windows XP SP2 on an HP Laptop (paviliion dv4000) and am attempting to run the program OpenRPG+. Program can be provided for replication of test as necessary. Duplicate processes are not observed in Windows Task Manager and a complete uninstallation and installation of the Python 2.5 language provides the same unknown error. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-29 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-14 21:30 Message: Logged In: YES user_id=149084 Originator: NO I'm sorry, I can't understand your report. Please tell me exactly how you are starting IDLE (using the icon? using a command window?) What does OpenRPG+ have to do with it, are you calling it along with IDLE? If so, please give me the command line and a url for the program. What does your "edit" have to do with the problem? The second number is illegal, because although it's coded as an octal (starts with 0) it has characters greater than 7 in it. Fix either of those issues, and it's fine. ---------------------------------------------------------------------- Comment By: Farhymn (farhymn) Date: 2006-11-20 11:53 Message: Logged In: YES user_id=1650037 Originator: YES (edit) Forgot to mention that the problem is pythonw.exe specific as well. Python DOS runs fine, I can only get it to register a token error by typing in the following at the prompt: 1234816587613289741-0152872349817230987 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 From noreply at sourceforge.net Sat Dec 30 04:20:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Dec 2006 19:20:21 -0800 Subject: [ python-Bugs-1614460 ] python-logging compatability with Zope. Message-ID: <200612300320.kBU3KLMo012619@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1614460, was opened at 2006-12-12 19:02 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: Python Library Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Simon Hookway (shookway) Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-29 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 09:13 Message: Logged In: YES user_id=308438 Originator: NO Yes, a fix was applied a while ago. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 00:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 From noreply at sourceforge.net Sat Dec 30 22:45:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Dec 2006 13:45:15 -0800 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 20:40 Message generated for change (Comment added) made by ooooooooo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- Comment By: Benjamin (ooooooooo) Date: 2006-12-30 21:45 Message: Logged In: YES user_id=1680023 Originator: NO I would also like to see this feature. I'm using Josiah Carlson's recipe for the time being. I'm agnostic about whether the asynchronicity is a "mode" or just a case of using different functions. However, if the former is chosen, then one should be able to switch modes at will, because sometimes I want blocking and sometimes I don't. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 20:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 20:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 19:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-29 00:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 23:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 23:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun Dec 31 00:21:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Dec 2006 15:21:59 -0800 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-30 15:21 Message: Logged In: YES user_id=341410 Originator: YES The way subprocess is currently written, if you were to use a blocking semantic, you would no longer be able to use an asynchronous semantic afterwards (it will read the result until there is nothing more to read). Note that this is the case whether it is mode or method based. ---------------------------------------------------------------------- Comment By: Benjamin (ooooooooo) Date: 2006-12-30 13:45 Message: Logged In: YES user_id=1680023 Originator: NO I would also like to see this feature. I'm using Josiah Carlson's recipe for the time being. I'm agnostic about whether the asynchronicity is a "mode" or just a case of using different functions. However, if the former is chosen, then one should be able to switch modes at will, because sometimes I want blocking and sometimes I don't. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 12:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 17:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun Dec 31 05:34:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Dec 2006 20:34:20 -0800 Subject: [ python-Bugs-1625205 ] sqlite3 documentation omits: close(), commit(), autocommit Message-ID: Bugs item #1625205, was opened at 2006-12-30 23:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625205&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kitbyaydemir (kitbyaydemir) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite3 documentation omits: close(), commit(), autocommit Initial Comment: The Python 2.5 Library documentation (HTML format), Section 13.13 (sqlite3) fails to mention several important methods of Connection objects. Specifically, the close() and commit() methods. Considering that autocommit mode is not the default, I'm not sure how a user is supposed to figure out that they need to call these methods to ensure that changes are reflected on disk. (The only reason I discovered these was from http://initd.org/tracker/pysqlite/wiki/basicintro .) Furthermore, Section 13.13.5 mentions the existence of "autocommit mode", but fails to describe what that mode is and why it might be useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625205&group_id=5470 From noreply at sourceforge.net Sun Dec 31 16:19:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Dec 2006 07:19:19 -0800 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 20:40 Message generated for change (Comment added) made by ooooooooo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- Comment By: Benjamin (ooooooooo) Date: 2006-12-31 15:19 Message: Logged In: YES user_id=1680023 Originator: NO If there were a blocking "read x bytes" type call, could you not do some non-blocking stuff afterwards? If you use the "read" method, with a byte limit, directly on the stdout member of Popen, that could return with your bytes, and then you do some non-blocking stuff afterwards. That's the external view of course, I suspect that you're saying there's some internal lower-level reason this is currently not possible. Thanks for your interim class BTW, it is proving to be very useful. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-30 23:21 Message: Logged In: YES user_id=341410 Originator: YES The way subprocess is currently written, if you were to use a blocking semantic, you would no longer be able to use an asynchronous semantic afterwards (it will read the result until there is nothing more to read). Note that this is the case whether it is mode or method based. ---------------------------------------------------------------------- Comment By: Benjamin (ooooooooo) Date: 2006-12-30 21:45 Message: Logged In: YES user_id=1680023 Originator: NO I would also like to see this feature. I'm using Josiah Carlson's recipe for the time being. I'm agnostic about whether the asynchronicity is a "mode" or just a case of using different functions. However, if the former is chosen, then one should be able to switch modes at will, because sometimes I want blocking and sometimes I don't. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 20:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 20:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 19:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-29 00:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 23:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 23:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From noreply at sourceforge.net Sun Dec 31 17:42:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Dec 2006 08:42:04 -0800 Subject: [ python-Bugs-1625381 ] re module documentation on search/match is unclear Message-ID: Bugs item #1625381, was opened at 2006-12-31 16:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Boulton (richardb) Assigned to: Nobody/Anonymous (nobody) Summary: re module documentation on search/match is unclear Initial Comment: Section 4.2.2 ("Matching vs Searching") of the Python Library Reference covers the match and search methods of regular expression objects. However, it doesn't begin by describing the difference between these methods. Each time I try to remember which way round match and search are, it takes several minutes of checking the documentation to work out which is which. I suggest that the first paragraph of the section is replaced with the following text (in two paragraphs), to make the distinction between the methods clearer: "Python offers two different primitive operations based on regular expressions: match and search. match() checks for a match at the beginning of the search string, whereas search() checks for a match anywhere in the string. If you want something equivalent to Perl's semantics, the search operation is what you're looking for. See the search() function and corresponding method of compiled regular expression objects." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&group_id=5470 From noreply at sourceforge.net Sun Dec 31 19:04:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 31 Dec 2006 10:04:28 -0800 Subject: [ python-Feature Requests-1191964 ] asynchronous Subprocess Message-ID: Feature Requests item #1191964, was opened at 2005-04-28 13:40 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&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: Josiah Carlson (josiahcarlson) Assigned to: Peter ?strand (astrand) Summary: asynchronous Subprocess Initial Comment: It would be terribly nice if the Popen class in the subprocess module would allow a programmer to easily say "send some data right now (if I have some to send) and receive whatever information is available right now". Essentially the equivalent of asyncore.loop(count=1), only that it returns the data received, instead of placing it in a buffer. Why would this functionality be useful? Currently, when using the subprocess module with pipes, the interaction with a pipe is limited to "send data if desired, close the subprocess' stdin, read all output from the subprocess' stdout, ...". Certainly one can pull the pipes out of the Popen instance, and perform the necessary functions on posix systems (with select or poll), but the additional magic on WIndows is a little less obvious (but still possible). There is a post by Paul Du Bois with an example using win32pipe.PeekNamedPipe: http://groups-beta.google.com/group/comp.lang.python/msg/115e9332cc1ca09d?hl=en And a message from Neil Hodgeson stating that PeekNamedPipe works on anonymous pipes: http://mail.python.org/pipermail/python-dev/2000-May/004200.html With this modification, creating Expect-like modules for any platform, as well as embedded shells inside any GUI with a text input widget, becomes easy. Heck, even Idle could use it rather than a socket for its interactive interpreter. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-31 10:04 Message: Logged In: YES user_id=341410 Originator: YES Unless you use PeekNamedPipe on Windows, there is no guarantee that the pipe will return *any* data until the process ends, even if you say pipe.read(1) and there is 1k of data already sent. Note that the two async reading methods that I provide (recv() and recv_err()) take a 'maximum bytes' argument. Just like I have written a 'send_all()' utility function, I (or you) can easily write a 'recv_exact()' utility function that receives an exact number of bytes before returning. That functionality would be more or less required for one of the expected use-cases I specify in the recipe, "writing a multi-platform 'expect' module". Stick with async calls (with the utility recv_exact()) until you need to use the .communicate() method. ---------------------------------------------------------------------- Comment By: Benjamin (ooooooooo) Date: 2006-12-31 07:19 Message: Logged In: YES user_id=1680023 Originator: NO If there were a blocking "read x bytes" type call, could you not do some non-blocking stuff afterwards? If you use the "read" method, with a byte limit, directly on the stdout member of Popen, that could return with your bytes, and then you do some non-blocking stuff afterwards. That's the external view of course, I suspect that you're saying there's some internal lower-level reason this is currently not possible. Thanks for your interim class BTW, it is proving to be very useful. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-12-30 15:21 Message: Logged In: YES user_id=341410 Originator: YES The way subprocess is currently written, if you were to use a blocking semantic, you would no longer be able to use an asynchronous semantic afterwards (it will read the result until there is nothing more to read). Note that this is the case whether it is mode or method based. ---------------------------------------------------------------------- Comment By: Benjamin (ooooooooo) Date: 2006-12-30 13:45 Message: Logged In: YES user_id=1680023 Originator: NO I would also like to see this feature. I'm using Josiah Carlson's recipe for the time being. I'm agnostic about whether the asynchronicity is a "mode" or just a case of using different functions. However, if the former is chosen, then one should be able to switch modes at will, because sometimes I want blocking and sometimes I don't. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:55 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-21 13:51 Message: Logged In: YES user_id=341410 I've implemented this as a subclass of subprocess.Popen in the Python cookbook, available here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440554 Essentially this is a request for inclusion in the standard library for Python 2.5 . ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 12:47 Message: Logged In: YES user_id=341410 How about if subprocesses have 3 new methods, send(input), recv(maxlen), and recv_stderr(maxlen). send(input) would perform like socket.send(), sending as much as it currently can, returning the number of bytes sent. recv(maxlen) and recv_stderr(maxlen) would recieve up to the provided number of bytes from the stdout or stderr pipes respectively. I currently have an implementation of the above on Windows and posix. I include the context diff against revision 1.20 of subprocess.py in current CVS. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 17:15 Message: Logged In: YES user_id=341410 I suppose I should mention one side-effect of all this. It requires three more functions from pywin32 be included in the _subprocess driver; win32file.ReadFile, win32file.WriteFile, and win32pipe.PeekNamedPipe . Read and Peek are for reading data from stdout and stderr, and Write is for the support for partial writes to stdin. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-28 16:22 Message: Logged In: YES user_id=341410 I've got a version of subprocess that has this functionality with pywin32. Making it work on *nix systems with usable select is trivial. About the only question is whether the functionality is desireable, and if so, what kind of API is reasonable. Perhaps adding an optional argument 'wait_for_completion' to the communicate method, which defaults to True for executing what is currently in the body of communicate. If the 'wait_for_completion' argument is untrue, then it does non-waiting asynchronous IO, returning either a 2 or 3-tuple on completion. If input is None, it is a 2-tuple of (stdout, stderr). If input is a string, it is a 3-tuple of (bytes_sent, stdout, stderr). How does that sound? ---------------------------------------------------------------------- Comment By: Dave Schuyler (parameter) Date: 2005-04-28 16:38 Message: Logged In: YES user_id=473331 More control of sub-processes would be great. Several times in the past few years I've done stuff with os.system, popenN, or spawn* and it would be useful to have even more cross-platform consistency and support in this area. Anyway, this is just a vote to encurage other developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191964&group_id=5470 From tavspam at gmail.com Tue Dec 12 22:59:10 2006 From: tavspam at gmail.com (Thomas) Date: Tue, 12 Dec 2006 21:59:10 -0000 Subject: difflib.SequenceMatcher fails for larger strings Message-ID: <493b81e30612121359va93193k5f51bfe55e13d4fd@mail.gmail.com> I'm trying to write a program to test a persons typing speed and show them their mistakes. However I'm getting weird results when looking for the differences in longer strings: import difflib a = '01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789' # now with a few mistakes b = '012345W7890123456789012W456789012345678901W3456789012345678901234567890W234567890123456789012345W789012345678901234567890123W567890123456W89012345678901234567W90123456789012W4567890123456W890123456789' s = difflib.SequenceMatcher(None, a, b) print s.get_matching_blocks() print s.get_opcodes() Is this a known bug? Would it just take to long to calculate?