From noreply at sourceforge.net Sat Apr 1 00:13:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 14:13:01 -0800 Subject: [ python-Bugs-1458017 ] Log._log needs to be more forgiving... Message-ID: Bugs item #1458017, was opened at 2006-03-24 21:17 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log._log needs to be more forgiving... Initial Comment: The _log method of distutils' Log class executes print msg % args where args might be an empty tuple (the methods that call _log all have varargs signatures). If that's the case and msg happens to contain a % sign, it barfs. It should be more forgiving, for instance: def _log(self, level, msg, args): if level >= self.threshold: try: print msg % args except TypeError: if not args: print msg else: raise sys.stdout.flush() I just corrected this locally for our 2.3 and 2.4 installations. The above is a bit ugly, but it does allow the common case (msg contains a % but an empty args list) to pass while still catching most programmer errors. Distutils is trying to log this message (wrapped): gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/app/mysql-5.0.19/include -I/opt/app/mysql-5.0.19/include -I/opt/lang/python/include/python2.3 -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=generic I suppose it would be better if all the places in distutils which log compiler commands without extra args escaped their % signs. This seems like an acceptable compromise though. Skip ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-03-31 22:13 Message: Logged In: YES user_id=1126061 This bug report should be closed. See patch #1462414 ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-03-28 17:45 Message: Logged In: YES user_id=1126061 Oh right, I understand now. Yeah the fix seems fine to me. Although, would it be more appropriate to check if not args: is True? So the _log() function would be something more like this: def _log(self, level, msg, args): if level >= self.threshold: if not args: print msg else: print msg % args sys.stdout.flush() Just thinking out-loud really.. not sure the check for the raised exception is really necessary. Thanks, Matt ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-03-28 03:58 Message: Logged In: YES user_id=44345 It barfs if you pass an empty tuple and the msg argument contains a % escape. For example, try: print "%s" % () In the particular case that tripped me up, it's trying to print a (bogus) gcc command which contains % escapes while passing no args to map them. ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-03-27 21:27 Message: Logged In: YES user_id=1126061 I can't reproduce on 2.4.2. Although maybe I misunderstood... Are you saying that _log() barfs when you pass an empty tuple? Passing an empty tuple to _log() works fine here.. I can understand it breaking when you pass some format string to args and the msg contains an '%', that's the developer's fault for not escaping the precentage sign. Could you clarify? Or am I totally wrong? Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 From noreply at sourceforge.net Sat Apr 1 00:16:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 14:16:42 -0800 Subject: [ python-Bugs-1462440 ] udp multicast setsockopt fails Message-ID: Bugs item #1462440, was opened at 2006-03-31 15:16 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=1462440&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: udp multicast setsockopt fails Initial Comment: Using setsockopt to join a multicast group for a udp socket fails on windows (works on linux). Test reproduction: run the attached file expected behavior: The snd thread sends three udp packets to the multicast address. The rcv thread reads three udp packets. observed behavior on linux: the expected behavior observed behavior on windows: Exception in thread rcv: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "C:\Python24\lib\threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "E:\svn\TTC\trunk\agrover\src\SmcTestCase\multicastbug.py", line 12, in rcv s.setsockopt(SOL_IP, IP_ADD_MEMBERSHIP, sopt) File "", line 1, in setsockopt error: (10022, 'Invalid argument') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462440&group_id=5470 From noreply at sourceforge.net Sat Apr 1 01:23:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 15:23:32 -0800 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:05:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:05:47 -0800 Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError Message-ID: Bugs item #1460340, was opened at 2006-03-28 19:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Tim Peters (tim_one) Summary: random.sample can raise KeyError Initial Comment: I have only tested this in 2.3 and the relevant code in random.py has changed in the current svn branch, but from inspection it looks to me like the bug may still be there. If you initialize a dictionary as follows: a={}.fromkeys(range(10)+range(10,100,2)+range(100,110)) then random.sample(a,3) raises KeyError most times that you call it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 19:05 Message: Logged In: YES user_id=31435 It's as easy to "make dicts work" as it is to forbid them, and since the test suite has implied for 30 months that dicts do work (by virtue of testing them with sample()), I wouldn't be comfortable making them raise an exception without going through the deprecation business. Fine by me if P3K drops sample(dict) support, though. WRT dicts, sampling from .values() doesn't make sense to me, but sampling from .keys() does. "for x in dict" iterates over the keys, and sample() clearly intends to try to generalize the documented "sequence" to "iterable" (albeit that it's not entirely successful, it's still useful, as especially in the case of sets). Online algorithms aren't attractive here because they take expected-case O(len(sequence)) time even for a sample size of 1. The current algorithms take O(k) time, and k (unlike the population) is almost always small. I suppose some yahoo may be doing sample(seq, len(seq)) as an idiotic way to spell shuffle(seq), but that's just natural selection in action ;-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-31 07:29 Message: Logged In: YES user_id=80475 It should be documented. Was noting that it (and dicts) currently are not. That gives us the freedom to change it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-31 06:42 Message: Logged In: YES user_id=72053 This notion of supporting sets without documenting it also seems screwy. I defer to you guys whether sets or dicts need to be supported, but if either is supported to the extent that someone is going to bother maintaining the code and test suite for it, IMO the support should be documented. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-31 06:37 Message: Logged In: YES user_id=80475 Sampling dict.values is screwy. If they want to sample a dictionary, they can be explicit about what they want by using d.keys() or d.values(). I prefer to completely forgo dict support and stick with sequences (as documented) and sets (supported but not documented). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-31 05:30 Message: Logged In: YES user_id=72053 It can handle dicts easily enough by sampling from population.values() instead of list(population), if it knows it's dealing with a dict. On clpy I suggested adding s.values() for sets so that the values in dicts and sets (and multisets if those get added) could be handled uniformly, but reception hasn't been good. I see there's an operator.isSequenceType function, that presumably checks for built-in sequence types, not arbitrary classes with __getattr__ methods that make them act like sequences. But maybe it's close enough to what we want, that the docs can say that random.sample is limited to sequences, sets, and (maybe) dicts. If it were up to me, I'd check for a .values() operation on non-sequences and use it if available, or raise TypeError otherwise. Then I'd add that operation to sets. There is also a very cute algorithm for doing random sampling from sequences of unknown length (iterators). I'm sure Tim and Ray know about it. Maybe I'll try coding it. The k=1 case (basically random.choice) looks like: for n,x in enumerate(seq): if random()*(n+1) < 1: c=x return [c] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-31 04:54 Message: Logged In: YES user_id=80475 It probably should not support dicts at all and should make some effort to detect them and raise a TypeError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-30 22:55 Message: Logged In: YES user_id=31435 Assigned to me. The current situation is unacceptable, because internal code comments and the test suite were left implying that random.sample() "should work" for dicts -- but it doesn't, and the failure modes are both subtle and silent. Note that my first example was utterly vanilla, using a small dict with a contiguous range of integer keys. That's not asking sample() to crack a safe, it's asking it to borrow candy from a dead baby ;-) I don't care a lot about the second example, but it would would also work right if dicts were forced into sample()'s first internal algorithm (and potential optimization be damned in the case of a dict). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-30 05:18 Message: Logged In: YES user_id=80475 Bah. I'm not overly concerned. It is a Python fact of life that objects defining __getitem__ cannot aways be clearly categorized as being either a sequence or a mapping but not both. You can add some additional checks like checking for a keys() method, but there is a limit to what you can do against these safe-cracking style efforts to trick the routine. I hope this quest for theoretical perfection doesn't lead to throwing the baby out with the bathwater. It would be ashamed to lose the automated choice of the best performing algorithm. If that happens, somebody's real-world use cases are certain to suffer. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-29 08:02 Message: Logged In: YES user_id=31435 Ya, this is flaky for dicts; re-opening. For example, >>> d = dict((i, complex(i, i)) for i in xrange(30)) >>> random.sample(d, 5) # ask for 5 and it samples values [(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)] >>> random.sample(d, 6) # ask for 6 and it samples keys [20, 11, 9, 4, 14, 1] That one doesn't have to do with internal exceptions, it has only to do with which of sample()'s internal algorithms gets used. Paul's point about potential bias is also a worry. Here's a full example: """ from random import sample d = dict.fromkeys(range(24)) d['x'] = 'y' count = hits = 0 while 1: count += 1 hits += sample(d, 1) == ['x'] if count % 10000 == 0: print count, "%.2f%%" % (100.0 * hits / count) """ Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4% of the time. Instead it gets selected 0.16% of the time (1/25**2 -- and Paul's analysis of why is on target). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-29 05:07 Message: Logged In: YES user_id=72053 Actually the previous comment is wrong too; 99% of the time, sample(a,1) will return None since that's the value connected to every key in the dictionary, i.e. it's population[j] for every j. The other 1% of the time, the dict gets converted to a list, and the sample returns a key from the dict rather than a value, which is certainly wrong. And you can see how the probabilities are still messed up if the values in the dict are distinct. I think it's ok to give up on dicts, but some warning should about it be added to the manual unless dict-like things somehow get detected in the code. It would be best to test for the object really being a sequence, but I don't know if such a test exists. Maybe one should be added. I'll leave it to you guys to reopen this bug if appropriate. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-29 04:46 Message: Logged In: YES user_id=72053 I don't think the fix at 43421 is quite right, but I can't easily test it in my current setup. Suppose a = dict.fromkeys(range(99) + ['x']) b = random.sample(a,1) 99% of the time, there's no KeyError and b gets set to [j] where j is some random integer. 1% of the time, there's a KeyError, random.sample is called recursively, and the recursive call returns [some integer j] 99% of the time, and returns ['x'] 1% of the time. So in total, ['x'] gets returned .01% of the time instead of 1% of the time. I think it's better to not set result[i]=population[j] inside the loop. Instead, just build up the selected set until it has enough indices; then try to make a result list using those indices, and if there's a KeyError, convert the population to a list and use the same selection set to make the results. gbrandl also correctly points out that a dict is not a sequence type, so maybe it's ok to just punt on dicts. But it's obvious from the code comments that somebody once wanted dicts to work, and it's reasonable for people to want sets to work. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-29 04:17 Message: Logged In: YES user_id=80475 Checked-in a fix. See revision 43420 and 43421. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-29 04:11 Message: Logged In: YES user_id=849994 random.sample is documented to take a sequence as its first argument. A dict is not a sequence type. I think you want random.sample(a.keys(), 3) or, for large dicts, random.sample(a.iterkeys(), 3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:17:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:17:59 -0800 Subject: [ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed Message-ID: Bugs item #1462485, was opened at 2006-04-01 00: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=1462485&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: StopIteration raised in body of 'with' statement suppressed Initial Comment: Given: @contextmanager def gen(): print '__enter__' try: yield finally: print '__exit__' with gen(): raise StopIteration('body') running the above results in: __enter__ __exit__ I would have expected instead __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise StopIteration('body') StopIteration: body Note that doing: with gen(): raise GeneratorExit('body') does the expected thing: __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:19:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:19:36 -0800 Subject: [ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed Message-ID: Bugs item #1462485, was opened at 2006-04-01 00:17 Message generated for change (Comment added) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: StopIteration raised in body of 'with' statement suppressed Initial Comment: Given: @contextmanager def gen(): print '__enter__' try: yield finally: print '__exit__' with gen(): raise StopIteration('body') running the above results in: __enter__ __exit__ I would have expected instead __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise StopIteration('body') StopIteration: body Note that doing: with gen(): raise GeneratorExit('body') does the expected thing: __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body ---------------------------------------------------------------------- >Comment By: Tim Delaney (tcdelaney) Date: 2006-04-01 00:19 Message: Logged In: YES user_id=603121 Attached code and results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:23:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:23:23 -0800 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-04-01 00:23 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=1462486&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:41:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:41:55 -0800 Subject: [ python-Bugs-1460340 ] random.sample can raise KeyError Message-ID: Bugs item #1460340, was opened at 2006-03-28 19:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Nobody/Anonymous (nobody) Summary: random.sample can raise KeyError Initial Comment: I have only tested this in 2.3 and the relevant code in random.py has changed in the current svn branch, but from inspection it looks to me like the bug may still be there. If you initialize a dictionary as follows: a={}.fromkeys(range(10)+range(10,100,2)+range(100,110)) then random.sample(a,3) raises KeyError most times that you call it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 19:41 Message: Logged In: YES user_id=31435 Closing again; dicts work "by brute force" now, on trunk and 2.4 branch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 19:05 Message: Logged In: YES user_id=31435 It's as easy to "make dicts work" as it is to forbid them, and since the test suite has implied for 30 months that dicts do work (by virtue of testing them with sample()), I wouldn't be comfortable making them raise an exception without going through the deprecation business. Fine by me if P3K drops sample(dict) support, though. WRT dicts, sampling from .values() doesn't make sense to me, but sampling from .keys() does. "for x in dict" iterates over the keys, and sample() clearly intends to try to generalize the documented "sequence" to "iterable" (albeit that it's not entirely successful, it's still useful, as especially in the case of sets). Online algorithms aren't attractive here because they take expected-case O(len(sequence)) time even for a sample size of 1. The current algorithms take O(k) time, and k (unlike the population) is almost always small. I suppose some yahoo may be doing sample(seq, len(seq)) as an idiotic way to spell shuffle(seq), but that's just natural selection in action ;-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-31 07:29 Message: Logged In: YES user_id=80475 It should be documented. Was noting that it (and dicts) currently are not. That gives us the freedom to change it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-31 06:42 Message: Logged In: YES user_id=72053 This notion of supporting sets without documenting it also seems screwy. I defer to you guys whether sets or dicts need to be supported, but if either is supported to the extent that someone is going to bother maintaining the code and test suite for it, IMO the support should be documented. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-31 06:37 Message: Logged In: YES user_id=80475 Sampling dict.values is screwy. If they want to sample a dictionary, they can be explicit about what they want by using d.keys() or d.values(). I prefer to completely forgo dict support and stick with sequences (as documented) and sets (supported but not documented). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-31 05:30 Message: Logged In: YES user_id=72053 It can handle dicts easily enough by sampling from population.values() instead of list(population), if it knows it's dealing with a dict. On clpy I suggested adding s.values() for sets so that the values in dicts and sets (and multisets if those get added) could be handled uniformly, but reception hasn't been good. I see there's an operator.isSequenceType function, that presumably checks for built-in sequence types, not arbitrary classes with __getattr__ methods that make them act like sequences. But maybe it's close enough to what we want, that the docs can say that random.sample is limited to sequences, sets, and (maybe) dicts. If it were up to me, I'd check for a .values() operation on non-sequences and use it if available, or raise TypeError otherwise. Then I'd add that operation to sets. There is also a very cute algorithm for doing random sampling from sequences of unknown length (iterators). I'm sure Tim and Ray know about it. Maybe I'll try coding it. The k=1 case (basically random.choice) looks like: for n,x in enumerate(seq): if random()*(n+1) < 1: c=x return [c] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-31 04:54 Message: Logged In: YES user_id=80475 It probably should not support dicts at all and should make some effort to detect them and raise a TypeError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-30 22:55 Message: Logged In: YES user_id=31435 Assigned to me. The current situation is unacceptable, because internal code comments and the test suite were left implying that random.sample() "should work" for dicts -- but it doesn't, and the failure modes are both subtle and silent. Note that my first example was utterly vanilla, using a small dict with a contiguous range of integer keys. That's not asking sample() to crack a safe, it's asking it to borrow candy from a dead baby ;-) I don't care a lot about the second example, but it would would also work right if dicts were forced into sample()'s first internal algorithm (and potential optimization be damned in the case of a dict). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-30 05:18 Message: Logged In: YES user_id=80475 Bah. I'm not overly concerned. It is a Python fact of life that objects defining __getitem__ cannot aways be clearly categorized as being either a sequence or a mapping but not both. You can add some additional checks like checking for a keys() method, but there is a limit to what you can do against these safe-cracking style efforts to trick the routine. I hope this quest for theoretical perfection doesn't lead to throwing the baby out with the bathwater. It would be ashamed to lose the automated choice of the best performing algorithm. If that happens, somebody's real-world use cases are certain to suffer. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-29 08:02 Message: Logged In: YES user_id=31435 Ya, this is flaky for dicts; re-opening. For example, >>> d = dict((i, complex(i, i)) for i in xrange(30)) >>> random.sample(d, 5) # ask for 5 and it samples values [(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)] >>> random.sample(d, 6) # ask for 6 and it samples keys [20, 11, 9, 4, 14, 1] That one doesn't have to do with internal exceptions, it has only to do with which of sample()'s internal algorithms gets used. Paul's point about potential bias is also a worry. Here's a full example: """ from random import sample d = dict.fromkeys(range(24)) d['x'] = 'y' count = hits = 0 while 1: count += 1 hits += sample(d, 1) == ['x'] if count % 10000 == 0: print count, "%.2f%%" % (100.0 * hits / count) """ Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4% of the time. Instead it gets selected 0.16% of the time (1/25**2 -- and Paul's analysis of why is on target). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-29 05:07 Message: Logged In: YES user_id=72053 Actually the previous comment is wrong too; 99% of the time, sample(a,1) will return None since that's the value connected to every key in the dictionary, i.e. it's population[j] for every j. The other 1% of the time, the dict gets converted to a list, and the sample returns a key from the dict rather than a value, which is certainly wrong. And you can see how the probabilities are still messed up if the values in the dict are distinct. I think it's ok to give up on dicts, but some warning should about it be added to the manual unless dict-like things somehow get detected in the code. It would be best to test for the object really being a sequence, but I don't know if such a test exists. Maybe one should be added. I'll leave it to you guys to reopen this bug if appropriate. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2006-03-29 04:46 Message: Logged In: YES user_id=72053 I don't think the fix at 43421 is quite right, but I can't easily test it in my current setup. Suppose a = dict.fromkeys(range(99) + ['x']) b = random.sample(a,1) 99% of the time, there's no KeyError and b gets set to [j] where j is some random integer. 1% of the time, there's a KeyError, random.sample is called recursively, and the recursive call returns [some integer j] 99% of the time, and returns ['x'] 1% of the time. So in total, ['x'] gets returned .01% of the time instead of 1% of the time. I think it's better to not set result[i]=population[j] inside the loop. Instead, just build up the selected set until it has enough indices; then try to make a result list using those indices, and if there's a KeyError, convert the population to a list and use the same selection set to make the results. gbrandl also correctly points out that a dict is not a sequence type, so maybe it's ok to just punt on dicts. But it's obvious from the code comments that somebody once wanted dicts to work, and it's reasonable for people to want sets to work. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-03-29 04:17 Message: Logged In: YES user_id=80475 Checked-in a fix. See revision 43420 and 43421. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-29 04:11 Message: Logged In: YES user_id=849994 random.sample is documented to take a sequence as its first argument. A dict is not a sequence type. I think you want random.sample(a.keys(), 3) or, for large dicts, random.sample(a.iterkeys(), 3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:44:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:44:17 -0800 Subject: [ python-Bugs-1457119 ] Unifying pickle and cPickle exception class hierarchies Message-ID: Bugs item #1457119, was opened at 2006-03-23 18:29 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470 Please note that this 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 Submitted By: Ori Peleg (oripel) Assigned to: Nobody/Anonymous (nobody) Summary: Unifying pickle and cPickle exception class hierarchies Initial Comment: Should the pickle and cPickle exception class hierarchies be unified? Perhaps just subclass one grandparent PickleError class? That way module copy_reg can throw exceptions from this hierarchy. Here's the experience that led to the thought: (1) confusing exception types when a class can't be pickled When an object can't be pickled, sometimes a TypeError is raised, and sometimes an exception derived from pickle.PickleError or cPickle.PickleError, a screenshot is pasted below. (2) copy_reg raises TypeError When a pickle-related exception occurs in copy_reg, a TypeError is raised, e.g. in line 69: raise TypeError, "can't pickle %s objects" % base.__name__ but if copy_reg wants to raise an exception from the pickle module's hierarchy... (3) copy_reg doesn't know if pickle or cPickle are used It can't choose between the two, therefore it chooses TypeError. === screenshot === >>> import sys, pickle, cPickle >>> try: raise RuntimeError ... except: tb = sys.exc_info()[-1] ... >>> frame = tb.tb_frame >>> pickle.dumps(frame) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 313, in save rv = reduce(self.proto) File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle frame objects >>> cPickle.dumps(frame) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle frame objects >>> pickle.dumps(tb) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 319, in save raise PicklingError("Can't pickle %r object: %r" % pickle.PicklingError: Can't pickle 'traceback' object: >>> cPickle.dumps(tb) Traceback (most recent call last): File "", line 1, in ? cPickle.UnpickleableError: Cannot pickle objects >>> ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-01 02:44 Message: Logged In: YES user_id=1326842 I don't think this is possible, since other modules than pickle and cPickle also rely on copy_reg module, e.g. the copy module. It would be even more surprising if a PicklingError would be raised when you try to copy an object. I think that this bug can be closed, and the submitter can open a feature request if he still think that it is worth the effort. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470 From noreply at sourceforge.net Sat Apr 1 02:56:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 16:56:19 -0800 Subject: [ python-Bugs-1457119 ] Unifying pickle and cPickle exception class hierarchies Message-ID: Bugs item #1457119, was opened at 2006-03-23 19:29 Message generated for change (Comment added) made by oripel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470 Please note that this 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 Submitted By: Ori Peleg (oripel) Assigned to: Nobody/Anonymous (nobody) Summary: Unifying pickle and cPickle exception class hierarchies Initial Comment: Should the pickle and cPickle exception class hierarchies be unified? Perhaps just subclass one grandparent PickleError class? That way module copy_reg can throw exceptions from this hierarchy. Here's the experience that led to the thought: (1) confusing exception types when a class can't be pickled When an object can't be pickled, sometimes a TypeError is raised, and sometimes an exception derived from pickle.PickleError or cPickle.PickleError, a screenshot is pasted below. (2) copy_reg raises TypeError When a pickle-related exception occurs in copy_reg, a TypeError is raised, e.g. in line 69: raise TypeError, "can't pickle %s objects" % base.__name__ but if copy_reg wants to raise an exception from the pickle module's hierarchy... (3) copy_reg doesn't know if pickle or cPickle are used It can't choose between the two, therefore it chooses TypeError. === screenshot === >>> import sys, pickle, cPickle >>> try: raise RuntimeError ... except: tb = sys.exc_info()[-1] ... >>> frame = tb.tb_frame >>> pickle.dumps(frame) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 313, in save rv = reduce(self.proto) File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle frame objects >>> cPickle.dumps(frame) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle frame objects >>> pickle.dumps(tb) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 319, in save raise PicklingError("Can't pickle %r object: %r" % pickle.PicklingError: Can't pickle 'traceback' object: >>> cPickle.dumps(tb) Traceback (most recent call last): File "", line 1, in ? cPickle.UnpickleableError: Cannot pickle objects >>> ---------------------------------------------------------------------- >Comment By: Ori Peleg (oripel) Date: 2006-04-01 03:56 Message: Logged In: YES user_id=1131251 In that case, how about making the pickle and cPickle exceptions subclass TypeError? Anyone using copy_reg and expecting a TypeError will be appeased. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-01 03:44 Message: Logged In: YES user_id=1326842 I don't think this is possible, since other modules than pickle and cPickle also rely on copy_reg module, e.g. the copy module. It would be even more surprising if a PicklingError would be raised when you try to copy an object. I think that this bug can be closed, and the submitter can open a feature request if he still think that it is worth the effort. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457119&group_id=5470 From noreply at sourceforge.net Sat Apr 1 03:13:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 17:13:43 -0800 Subject: [ python-Bugs-1452246 ] htmllib doesn't properly substitute entities Message-ID: Bugs item #1452246, was opened at 2006-03-17 03:57 Message generated for change (Comment added) made by rvernica You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452246&group_id=5470 Please note that this 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 Submitted By: Helmut Grohne (gnarfk) Assigned to: Nobody/Anonymous (nobody) Summary: htmllib doesn't properly substitute entities Initial Comment: I'd like to illustrate and suggest a fix by showing a simple python file (which was named htmllib2.py so you can uncomment the line in the doctest case to see that my fix works). It's more like a hack than the fix though: #!/usr/bin/env python2.4 """ Use this instead of htmllib for having entitydefs substituted in attributes,too. Example: >>> import htmllib # >>> import htmllib2 as htmllib >>> import formatter >>> import StringIO >>> s = StringIO.StringIO() >>> p = htmllib.HTMLParser(formatter.AbstractFormatter(formatter.DumbWriter(s))) >>> p.feed('<>&') >>> s.getvalue() '<>&' """ __all__ = ("HTMLParser",) import htmllib from htmlentitydefs import name2codepoint as entitytable entitytable = dict([(k, chr(v)) for k, v in entitytable.items() if v < 256]) def entitysub(s): ret = "" state = "" for c in s: if state.startswith('&'): if c == ';': ret += entitytable.get(state[1:], '%s;' % state) state = "" else: state += c elif c == '&': state = c else: ret += c return ret class HTMLParser(htmllib.HTMLParser): def handle_starttag(self, tag, method, attrs): """Repair attribute values.""" attrs = [(k, entitysub(v)) for (k, v) in attrs] method(attrs) if __name__ == '__main__': import doctest doctest.testmod() ---------------------------------------------------------------------- Comment By: Rares Vernica (rvernica) Date: 2006-03-31 17:13 Message: Logged In: YES user_id=1491427 This bug has been fixed on patch #1462498. Ray ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452246&group_id=5470 From noreply at sourceforge.net Sat Apr 1 03:16:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 17:16:05 -0800 Subject: [ python-Bugs-1452246 ] htmllib doesn't properly substitute entities Message-ID: Bugs item #1452246, was opened at 2006-03-17 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=1452246&group_id=5470 Please note that this 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 Submitted By: Helmut Grohne (gnarfk) Assigned to: Nobody/Anonymous (nobody) Summary: htmllib doesn't properly substitute entities Initial Comment: I'd like to illustrate and suggest a fix by showing a simple python file (which was named htmllib2.py so you can uncomment the line in the doctest case to see that my fix works). It's more like a hack than the fix though: #!/usr/bin/env python2.4 """ Use this instead of htmllib for having entitydefs substituted in attributes,too. Example: >>> import htmllib # >>> import htmllib2 as htmllib >>> import formatter >>> import StringIO >>> s = StringIO.StringIO() >>> p = htmllib.HTMLParser(formatter.AbstractFormatter(formatter.DumbWriter(s))) >>> p.feed('<>&') >>> s.getvalue() '<>&' """ __all__ = ("HTMLParser",) import htmllib from htmlentitydefs import name2codepoint as entitytable entitytable = dict([(k, chr(v)) for k, v in entitytable.items() if v < 256]) def entitysub(s): ret = "" state = "" for c in s: if state.startswith('&'): if c == ';': ret += entitytable.get(state[1:], '%s;' % state) state = "" else: state += c elif c == '&': state = c else: ret += c return ret class HTMLParser(htmllib.HTMLParser): def handle_starttag(self, tag, method, attrs): """Repair attribute values.""" attrs = [(k, entitysub(v)) for (k, v) in attrs] method(attrs) if __name__ == '__main__': import doctest doctest.testmod() ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:16 Message: Logged In: YES user_id=31435 Thanks, Ray! Closing as Fixed. ---------------------------------------------------------------------- Comment By: Rares Vernica (rvernica) Date: 2006-03-31 20:13 Message: Logged In: YES user_id=1491427 This bug has been fixed on patch #1462498. Ray ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452246&group_id=5470 From noreply at sourceforge.net Sat Apr 1 03:36:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 17:36:30 -0800 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 1 03:37:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 17:37:24 -0800 Subject: [ python-Bugs-1326448 ] set.__getstate__ is not overriden Message-ID: Bugs item #1326448, was opened at 2005-10-14 08:38 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Sakkis (gsakkis) Assigned to: Tim Peters (tim_one) Summary: set.__getstate__ is not overriden Initial Comment: >>> import pickle >>> class Foo(set): ... def __getstate__(self): assert False >>> pickle.dumps(Foo()) # doesn't raise AssertionError The same happens with frozenset. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-01 03:37 Message: Logged In: YES user_id=1326842 The problem is that __reduce__() and __reduce_ex__() have complete control over the process of pickling. The simple solution would be to switch to the __getnewargs__() method for pickle protocol 2 (this is simple, __getnewargs__() should return a tuple which is passed to the constructor when unpickling. This means that you can reuse the part of the current code that creates the args tuple) For protocols 0 and 1, the following should be added to the copy_reg module: def pickle_set(s): return set, list(s) pickle(set, pickle_set, set) def pickle_frozenset(s): return frozenset, list(s) pickle(set, pickle_set, set) The other options are: - copy the semantics from object_reduce_ex - add support directly to pickle and cPickle ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 16:37 Message: Logged In: YES user_id=80475 Tim, do you have any thoughts on this? I'm unclear on whether this is a bug in set(), in copy_reg, in pickle, or even a bug at all. setobject.c implements pickling via a __reduce__() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326448&group_id=5470 From noreply at sourceforge.net Sat Apr 1 03:43:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 17:43:41 -0800 Subject: [ python-Bugs-931877 ] Segfault in object_reduce_ex Message-ID: Bugs item #931877, was opened at 2004-04-08 19:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault in object_reduce_ex Initial Comment: Shane Hathaway bumped into this, unbounded recursion in typeobject.c's object_reduce_ex(). This occurs in Python 2.3.3 and current CVS. Assigned to Guido, to ponder whether object_reduce_ex is doing what it should; if it is (which seems likely to me), I suppose we need to inject a recursion counter to prevent the segfault. The failing case is short, but I'll attach it (temp99.py) to avoid SF line mangling. While the test uses pickle, same symptom if it's changed to use cPickle instead. Jim Fulton's analysis: """ This is a very clever infinite loop. The proxy doesn't actually proxy, but it does manage to confuse reduce about what's going on. reduce tries to figure out if it has been overridden by asking whether the class's reduce is the same as object.__reduce__. It doesn't expect to be lied to about the class. Things wouldn't have been so bad if the proxy had proxied __reduce__ as well as __class__. """ The priority hasn't been bumped, because "the real code" from which this was whittled down wasn't doing what it needed to do anyway, and the recursion went away when the real code was repaired. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-01 03:43 Message: Logged In: YES user_id=1326842 See patch #1462488. If that patch is accepted, this bug should be closed as fixed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:05 Message: Logged In: YES user_id=6380 Unassigning. I need to concentrate on Python 3000. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:58 Message: Logged In: YES user_id=1188172 Still crashing with 2.5... ---------------------------------------------------------------------- Comment By: Nathan Srebro (nati) Date: 2004-11-30 02:26 Message: Logged In: YES user_id=63133 This infinite recursion also occurs in another place, that got me stumped for a couple of days when old code that worked with Python 2.2 stopped working. If __class__ is not fidgeted with (as in original bug report), but a descriptor returns a custom reduce for the class, but not for its objects, reduce enters an infinite loop on the object: """ class descriptor_for_reduce(object): def __get__(self,obj,tp=None): if obj is not None: return super(ASpecialClass,obj).__reduce__ return self.reducer def reducer(self,proto=None): return "VerySpecial" class ASpecialClass(object): __reduce__ = descriptor_for_reduce() copy.copy(ASpecialClass()) """ ASpecialClass().__reduce__ is object.__reduce__, which is implemented by typeobject.c:object_reduce_ex. This function (that doesn't know if its called as the __reduce__ or the __reduce_ex__ method) tries to detect if the object's __reduce__ is overridden. It does so by checking if the object's class's __reduce__ is overridden, and in fact it is. It then assumes that the object's __reduce__ is overridden, and calls it. But the object's __reduce__ is the same function, causing the infinite loop. If __reduce_ex__ is used instead of __reduce__, the problem goes away, ASpecialClass().__reduce_ex__() return the usual tuple, and ASpecialClass.__reduce_ex__() return "VerySpecial". But when __reduce__ is overridden, ASpecialClass().__reduce__() enters an infinite loop. I believe this is a legitimate example that should behave just as when __reduce_ex__ is overridden. The example doesn't lie about __class__, and it is certainly legitimate for define a property that behaves differently for the class and for its objects. Where did this come up and why would I ever care about a class's __reduce__? The __reduce__ attribute of a class is never used by (the standard) pickle or copy, since save_global() is called instead. However, I have a custom pickler, implemented as a subclass of pickle.Pickler, which falls back on the class's __reduce__ when save_global() fails. This way, I can pickle certain classes that are created at run-time (and can be easily recreated, e.g. from their bases and dictionaries). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-04-08 19:51 Message: Logged In: YES user_id=31435 Hmm! The temp99.py download link doesn't work for me. Here's the content in case it doesn't work for others either: """ import cPickle as pickle from pickle import dumps class SimpleItem: def __reduce__(self): return (self.__class__, None, {}) class Proxy(object): __class__ = property(lambda self: self.__target.__class__) def __init__(self, target): self.__target = target def __getstate__(self): raise RuntimeError("No don't pickle me! Aaarrgghh!") p = Proxy(SimpleItem()) dumps(p) """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 From noreply at sourceforge.net Sat Apr 1 09:02:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 23:02:31 -0800 Subject: [ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed Message-ID: Bugs item #1462485, was opened at 2006-04-01 00:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 Please note that this 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: 7 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Nick Coghlan (ncoghlan) Summary: StopIteration raised in body of 'with' statement suppressed Initial Comment: Given: @contextmanager def gen(): print '__enter__' try: yield finally: print '__exit__' with gen(): raise StopIteration('body') running the above results in: __enter__ __exit__ I would have expected instead __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise StopIteration('body') StopIteration: body Note that doing: with gen(): raise GeneratorExit('body') does the expected thing: __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:02 Message: Logged In: YES user_id=849994 Nick, I can't tell whether this is intentional without rereading the specs. Can you? ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2006-04-01 00:19 Message: Logged In: YES user_id=603121 Attached code and results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 From noreply at sourceforge.net Sat Apr 1 09:08:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 23:08:22 -0800 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) >Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Sat Apr 1 09:23:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 23:23:25 -0800 Subject: [ python-Bugs-1462278 ] Coercion rules incomplete in Reference Manual Message-ID: Bugs item #1462278, was opened at 2006-03-31 17:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462278&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Coercion rules incomplete in Reference Manual Initial Comment: The eighth item in that list says: Exception to the previous item: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class, the right operand's __rop__() method is tried before the left operand's __op__() method. This is done so that a subclass can completely override binary operators. Otherwise, the left operand's __op__ method would always accept the right operand: when an instance of a given class is expected, an instance of a subclass of that class is always acceptable. This is not correct; subclass's __rop__() method is called only if it has overloaded the base class's method; example:: class A(object): def __add__(self, other): return self.__class__.__name__ __radd__ = __add__ class B(A):pass a = A() b = B() print b + a # prints B print a + b # prints A According to the docs B should be printed in both cases. The change in behaviour was introduced in revision 30639. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:23 Message: Logged In: YES user_id=849994 Thanks, fixed in rev. 43521, 43522. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462278&group_id=5470 From noreply at sourceforge.net Sat Apr 1 09:33:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 23:33:46 -0800 Subject: [ python-Bugs-1460564 ] Misleading documentation for socket.fromfd() Message-ID: Bugs item #1460564, was opened at 2006-03-29 09:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470 Please note that this 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 Submitted By: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading documentation for socket.fromfd() Initial Comment: The socket.fromfd() method does not correctly document what it does, in a way that is likely to cause users to leak file descriptors. Proposed fix: --- Modules/socketmodule.c 2005-09-14 20:15:03.000000000 +0200 +++ /home/msmith/src/Python-2.4.2/Modules/socketmodule.c 2006-03-29 11:28:35.000000000 +0200 @@ -3077,7 +3077,8 @@ PyDoc_STRVAR(fromfd_doc, "fromfd(fd, family, type[, proto]) -> socket object\n\ \n\ -Create a socket object from the given file descriptor.\n\ +Duplicate the given file descriptor, and create a socket\n\ +object from the duplicate.\r\ The remaining arguments are the same as for socket()."); #endif /* NO_DUP */ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:33 Message: Logged In: YES user_id=849994 I'm not going to remove the dup() since it may be relied upon in existing code. I've corrected the docs in rev. 43523, 43524. ---------------------------------------------------------------------- Comment By: Mike Howard (mikeh-id) Date: 2006-03-31 18:00 Message: Logged In: YES user_id=1195975 I still believe that fromfd() is in error in dup'ing the supplied file descriptor. This is because fromfd() is designed only for limited use and because duplication can be handled in other ways. It is unlikely anyone would intentitionally close both the file descriptor and the socket. The Library Documentation for includes the comment "This function is rarely needed, but can be used to get or set socket options on a socket passed to a program as standard input or output (such as a server started by the Unix inet daemon). The socket is assumed to be in blocking mode. Availability: Unix." I can't conceive of any case where it would be necessary for this function to dup() the file descriptor which couldn't be handled using the socket object dup() method. Using the socket object method would be more transparent than hiding the dup() within fromfd() and makes the documentation consistent. Regarding breaking existing code: - I just tested multiple calls of sys.stdin/stdout.close() and they run w/o error, so closing the socket derived from either will not cause problems if someone closes the underlying file descriptor. ---------------------------------------------------------------------- Comment By: Mike Howard (mikeh-id) Date: 2006-03-31 17:49 Message: Logged In: YES user_id=1195975 I don't believe the comment is incorrect, but I think the code should be changed to reflect the comment. socket.fromfd() is designed to be used when stdin/out/err are inhereted from an invoking process - most probably inetd. In this case, we get a file descriptor for an entity which is really a socket and we need a socket in order to perform i/o properly. Consequently, I think it is an error to dup() the fd within 'fromfd'. ---------------------------------------------------------------------- Comment By: Michael Smith (mlrsmith) Date: 2006-03-31 17:12 Message: Logged In: YES user_id=1488997 It is not an error to dup() the fd here, but it IS behaviour that the process calling socket.fromfd() must know about. Also, changing this behaviour will probably break most users of this API, since I don't see any way to use it correctly without knowing that it does, in fact, dup() the FD (my code reviously leaked file descriptors because I didn't know this). Breaking existing applications is bad, hence my suggestion to augment the documentation. FWIW: my app receives file descriptors - which are sockets - over a unix socket using sendmsg/recvmsg, for which I have an extension written in C. Using socket.fromfd() on this FD works perfectly, but I need to then os.close(fd) the original FD to avoid leaking it. ---------------------------------------------------------------------- Comment By: Mike Howard (mikeh-id) Date: 2006-03-31 16:52 Message: Logged In: YES user_id=1195975 I don't believe the comment is incorrect, but I think the code should be changed to reflect the comment. socket.fromfd() is designed to be used when stdin/out/err are inhereted from an invoking process - most probably inetd. In this case, we get a file descriptor for an entity which is really a socket and we need a socket in order to perform i/o properly. Consequently, I think it is an error to dup() the fd within 'fromfd'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470 From noreply at sourceforge.net Sat Apr 1 09:47:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 23:47:13 -0800 Subject: [ python-Bugs-1458017 ] Log._log needs to be more forgiving... Message-ID: Bugs item #1458017, was opened at 2006-03-24 21:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log._log needs to be more forgiving... Initial Comment: The _log method of distutils' Log class executes print msg % args where args might be an empty tuple (the methods that call _log all have varargs signatures). If that's the case and msg happens to contain a % sign, it barfs. It should be more forgiving, for instance: def _log(self, level, msg, args): if level >= self.threshold: try: print msg % args except TypeError: if not args: print msg else: raise sys.stdout.flush() I just corrected this locally for our 2.3 and 2.4 installations. The above is a bit ugly, but it does allow the common case (msg contains a % but an empty args list) to pass while still catching most programmer errors. Distutils is trying to log this message (wrapped): gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/app/mysql-5.0.19/include -I/opt/app/mysql-5.0.19/include -I/opt/lang/python/include/python2.3 -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=generic I suppose it would be better if all the places in distutils which log compiler commands without extra args escaped their % signs. This seems like an acceptable compromise though. Skip ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:47 Message: Logged In: YES user_id=849994 Fixed in rev. 43529, 43530. ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-03-31 22:13 Message: Logged In: YES user_id=1126061 This bug report should be closed. See patch #1462414 ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-03-28 17:45 Message: Logged In: YES user_id=1126061 Oh right, I understand now. Yeah the fix seems fine to me. Although, would it be more appropriate to check if not args: is True? So the _log() function would be something more like this: def _log(self, level, msg, args): if level >= self.threshold: if not args: print msg else: print msg % args sys.stdout.flush() Just thinking out-loud really.. not sure the check for the raised exception is really necessary. Thanks, Matt ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-03-28 03:58 Message: Logged In: YES user_id=44345 It barfs if you pass an empty tuple and the msg argument contains a % escape. For example, try: print "%s" % () In the particular case that tripped me up, it's trying to print a (bogus) gcc command which contains % escapes while passing no args to map them. ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-03-27 21:27 Message: Logged In: YES user_id=1126061 I can't reproduce on 2.4.2. Although maybe I misunderstood... Are you saying that _log() barfs when you pass an empty tuple? Passing an empty tuple to _log() works fine here.. I can understand it breaking when you pass some format string to args and the msg contains an '%', that's the developer's fault for not escaping the precentage sign. Could you clarify? Or am I totally wrong? Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 From noreply at sourceforge.net Sat Apr 1 09:57:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 31 Mar 2006 23:57:44 -0800 Subject: [ python-Bugs-947906 ] calendar.weekheader(n): n should mean chars not bytes Message-ID: Bugs item #947906, was opened at 2004-05-04 20:38 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: calendar.weekheader(n): n should mean chars not bytes Initial Comment: calendar.weekheader(n) is locale aware, which is good in principle. The parameter n, however, is interpreted as meaning bytes, not chars, which can generate broken strings for, e.g. localized weekday names: >>> calendar.weekheader(2) 'Mo Tu We Th Fr Sa Su' >>> locale.setlocale(locale.LC_ALL, "pt_BR.UTF-8") 'pt_BR.UTF-8' >>> calendar.weekheader(2) 'Se Te Qu Qu Se S\xc3 Do' Notice how "S?bado" (Saturday) above is missing the second utf-8 byte for the encoding of "?": >>> u"S?".encode("utf-8") 'S\xc3\xa1' The implementation of weekheader (and of all of calendar.py, it seems) is based on localized 8 bit strings. I suppose the correct fix for this bug will involve a roundtrip thru unicode. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-04-01 09:57 Message: Logged In: YES user_id=89016 Checked in calendar3,diff (minus the test) as r43531. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-31 19:45 Message: Logged In: YES user_id=89016 This third patch (calendar3.diff) is a variant of of the second patch, that uses xmlcharrefreplace error handling in the HTML calendar. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-31 19:36 Message: Logged In: YES user_id=89016 This second patch (calendar2.diff) adds new subclasses LocaleTextCalendar and LocaleHTMLCalendar that output localized month and weekday names and can cope with encodings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-31 19:11 Message: Logged In: YES user_id=89016 Checked in calendar.diff as r43483. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-31 17:14 Message: Logged In: YES user_id=89016 Here's a new version of the patch with documentation for the Calendar classes and a new test. The script interface isn't documented in the TeX file (python -mcalendar --help should be enough). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-07-21 21:17 Message: Logged In: YES user_id=89016 The following patch doesn't fix the unicode problem, but it should enable us to have both 8bit and unicode calendars. It reimplements the calendar functionality as classes. This makes it possible to reuse the date calculation logic and extend or replace the string formatting logic. Implementing a unicode version would be done by subclassing TextCalendar and overwritting formatweekday() and formatmonthname(). The patch adds several other features: A HTML version of a calendar can be output. (An example output can be found at http://styx.livinglogic.de/~walter/calendar/calendar.html). The calendar module can be used as a script from the command line. Various options are available. It's possible to specify the number of months per row (they were fixed at 3 in the old version). If this patch is accepted I can provide documentation and tests. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-06-03 06:43 Message: Logged In: YES user_id=21627 Adding an ucalendar module would be reasonable, IMO. Introducing ustrftime is not necessary - we could just apply the "unicode in/unicode out" procedure (i.e. if the format is a Unicode string, return a Unicode result). The tricky part of that is to convert the strftime result to Unicode. We could try mbstowcs, but that would fail if the locale doesn't use Unicode for wchar_t. Once ucalendar is written, we could document that the calendar module has known problems if the locale's encoding is not Latin-1. However, I'm not going to implement that any time soon, so unassigning. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-02 21:08 Message: Logged In: YES user_id=89016 Maybe we should have a second version of calendar (named ucalendar?) that works with unicode strings? Could those two modules be rewritten to use as much common functionality as possible? Or we could use a module global to configure whether str or unicode should be returned? Most of the localization functionality in calendar seems to come from datetime.datetime.strftime(), so it probably would help to have a method datetime.datetime.ustrftime() that returns the formatted string as unicode (using the locale encoding). Assigning to MvL as the locale/unicode expert. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-05-08 01:57 Message: Logged In: YES user_id=55188 I think calendar.weekheader should mean not chars nor bytes but width. Because the function is currectly used for fixed width representations of calendars. Yes. They are same for western alphabets. But, for many of CJK characters are in full width. So, they need only 1 character for calendar.weekheader(2); and it's conventional in real life, too. But, we don't have unicode.width() support to implement the feature yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470 From noreply at sourceforge.net Sat Apr 1 16:14:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 06:14:20 -0800 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: splitscreen (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Sat Apr 1 17:16:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 07:16:13 -0800 Subject: [ python-Bugs-1451341 ] msgfmt.py: fuzzy messages not correctly found Message-ID: Bugs item #1451341, was opened at 2006-03-16 15:00 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Hanno Schlichting (hannosch) Assigned to: Nobody/Anonymous (nobody) Summary: msgfmt.py: fuzzy messages not correctly found Initial Comment: In the msgfmt.py script which is installed in %PYTHON_HOME%\Tools\i18n (on Windows) on line 129 to 131 it says: # Record a fuzzy mark if l[:2] == '#,' and l.find('fuzzy'): fuzzy = 1 this should be: # Record a fuzzy mark if l[:2] == '#,' and l.find('fuzzy') > -1: fuzzy = 1 or all lines beginning with '#,' will be treated as fuzzy. Only change is the "> -1". This applies to all versions of Python. It has been brought to my attention by Andrey Lebedev who found this in a product which uses a slightly modified msgfmt.py. ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-04-01 15:16 Message: Logged In: YES user_id=1126061 Yup, the bug is in trunk. Although I suggest # Record a fuzzy mark if l[:2] == '#,' and 'fuzzy' in l: as it's more readable (and I got shouted at by Tim the other day for using s.find() when 'in' would have done). Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470 From noreply at sourceforge.net Sat Apr 1 17:22:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 07:22:31 -0800 Subject: [ python-Bugs-1462700 ] Errors in PCbuild Message-ID: Bugs item #1462700, was opened at 2006-04-01 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=1462700&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in PCbuild Initial Comment: pcbuild.sln: pythoncore has a different GUID to pythoncore.vsproj. _ctypes_test needs to be dependent on _ctypes. Diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 From noreply at sourceforge.net Sat Apr 1 17:40:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 07:40:18 -0800 Subject: [ python-Bugs-1462706 ] urllib2 bails if the localhost doens't have a fqdn hostname Message-ID: Bugs item #1462706, was opened at 2006-04-01 15: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=1462706&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 bails if the localhost doens't have a fqdn hostname Initial Comment: When running the test suite I ran into a similar problem to bug #1257988. in the FileHandler class's get_names() method should be wrapped in a try, except block because it shouldn't assume that the localhost has a fqdn hostname. Attached is a minimal diff against trunk r43542. Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 From noreply at sourceforge.net Sat Apr 1 21:32:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 11:32:17 -0800 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: splitscreen (splitscreen) Date: 2006-04-01 19:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Sat Apr 1 22:43:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 12:43:19 -0800 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 20:43 Message: Logged In: YES user_id=849994 Yes, I want to remove 'U' from the mode since it's at this point already recognized by Python, and it's not meaningful to the underlying C library. ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-04-01 19:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Sat Apr 1 23:59:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 13:59:02 -0800 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: splitscreen (splitscreen) Date: 2006-04-01 21:59 Message: Logged In: YES user_id=1126061 Ok, uploading latest patch, not quite sure I've hit the mark here. Please review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 20:43 Message: Logged In: YES user_id=849994 Yes, I want to remove 'U' from the mode since it's at this point already recognized by Python, and it's not meaningful to the underlying C library. ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-04-01 19:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: splitscreen (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Sun Apr 2 00:33:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 14:33:14 -0800 Subject: [ python-Bugs-1462700 ] Errors in PCbuild Message-ID: Bugs item #1462700, was opened at 2006-04-01 15:22 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Martin v. L??wis (loewis) Summary: Errors in PCbuild Initial Comment: pcbuild.sln: pythoncore has a different GUID to pythoncore.vsproj. _ctypes_test needs to be dependent on _ctypes. Diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 From noreply at sourceforge.net Sun Apr 2 00:35:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 14:35:44 -0800 Subject: [ python-Bugs-1462706 ] urllib2 bails if the localhost doens't have a fqdn hostname Message-ID: Bugs item #1462706, was opened at 2006-04-01 16:40 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 Please note that this 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 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 bails if the localhost doens't have a fqdn hostname Initial Comment: When running the test suite I ran into a similar problem to bug #1257988. in the FileHandler class's get_names() method should be wrapped in a try, except block because it shouldn't assume that the localhost has a fqdn hostname. Attached is a minimal diff against trunk r43542. Matt ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 23:35 Message: Logged In: YES user_id=261020 This fixes the test failure and is safe. I don't know if a more sophisticated patch is possible, but if nobody comes up with one, I think this should be applied (as happened with #1257988). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 From noreply at sourceforge.net Sun Apr 2 03:57:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 17:57:07 -0800 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sun Apr 2 04:08:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 18:08:07 -0800 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-01 21:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sun Apr 2 04:42:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Apr 2006 18:42:51 -0800 Subject: [ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed Message-ID: Bugs item #1462485, was opened at 2006-04-01 00:17 Message generated for change (Comment added) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 Please note that this 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: 7 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nick Coghlan (ncoghlan) Summary: StopIteration raised in body of 'with' statement suppressed Initial Comment: Given: @contextmanager def gen(): print '__enter__' try: yield finally: print '__exit__' with gen(): raise StopIteration('body') running the above results in: __enter__ __exit__ I would have expected instead __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise StopIteration('body') StopIteration: body Note that doing: with gen(): raise GeneratorExit('body') does the expected thing: __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body ---------------------------------------------------------------------- >Comment By: Tim Delaney (tcdelaney) Date: 2006-04-02 02:42 Message: Logged In: YES user_id=603121 Attached diffs to test_with.py which adds tests for raising StopIteration (and GeneratorExit) from the body of a with-statement where the context manager is either a generator, or a class instance. I think the correct behaviour is to return False from GeneratorContextManager.__exit__ if the thrown exception is a StopIteration, and the exact same instance is raised from self.gen.throw(). Diffs for this also attached. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:02 Message: Logged In: YES user_id=849994 Nick, I can't tell whether this is intentional without rereading the specs. Can you? ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2006-04-01 00:19 Message: Logged In: YES user_id=603121 Attached code and results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 From noreply at sourceforge.net Sun Apr 2 05:23:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 1 Apr 2006 19:23:02 -0800 Subject: [ python-Bugs-1427552 ] tarfile.open bug / corrupt data Message-ID: <200604020323.k323N2H2013181@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1427552, was opened at 02/08/06 06:13 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1427552&group_id=5470 Please note that this 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.4 >Status: Closed Resolution: None Priority: 7 Submitted By: Chris86 (chris86) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.open bug / corrupt data Initial Comment: Hi! I want to create a bz2 compressed tar file. Here is my code: full="/home/test/test.sql" tar = tarfile.open("test.tar.bz2", "w:bz2") tarinfo = tar.gettarinfo(full,"blubb.sql") tar.addfile(tarinfo,file(full)) tar.close() i think this should work, but the sql file is corrupt: - the created sql file in the compressed tar has only 4745 Lines, the original file has 4753 Regards, Chris ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 04/01/06 19:23 Message: Logged In: YES user_id=1312539 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: Neal Norwitz (nnorwitz) Date: 02/11/06 22:21 Message: Logged In: YES user_id=33168 Chris can you attach your sql file (or a small test case) so we can reproduce the problem? ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 02/08/06 07:13 Message: Logged In: YES user_id=642936 Just to identify whether this is a tarfile or bz2 module related issue: - Do you have the same problem without compression or with gzip compression? - Have you tried compressing your sql file directly with the bz2 module? ---------------------------------------------------------------------- Comment By: Chris86 (chris86) Date: 02/08/06 06:17 Message: Logged In: YES user_id=1133569 same error with Python 2.3.5 (#2, Aug 30 2005, 15:50:26) [GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2 ---------------------------------------------------------------------- Comment By: Chris86 (chris86) Date: 02/08/06 06:15 Message: Logged In: YES user_id=1133569 I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48) [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1427552&group_id=5470 From noreply at sourceforge.net Sun Apr 2 16:03:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 07:03:37 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 15: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=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Sun Apr 2 16:28:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 07:28:39 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 15:03 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 15:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Sun Apr 2 19:18:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 10:18:41 -0700 Subject: [ python-Bugs-1463104 ] problems with os.system and shell redirection on Windows XP Message-ID: Bugs item #1463104, was opened at 2006-04-02 17: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=1463104&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: problems with os.system and shell redirection on Windows XP Initial Comment: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 - Windows XP SP2 N.B. sorry for italian error messages. With the following script: # redirection.py import os import sys os.system(sys.argv[1]) ---------------- When doing: redirection.py "dir" > redirection.txt I obtain: Spazio su disco insufficiente. Instead with: redirection.py "svn help" > redirection.txt svn: Errore di scrittura: Bad file descriptor This is a Python problem because with an equivalent program written in C++: // redirection.c++ #include int main(int argc, char** argv) { std::system(argv[1]); } --------------------------------- there are no problems. Thanks and regards Manlio Perillo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463104&group_id=5470 From noreply at sourceforge.net Sun Apr 2 19:40:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 10:40:08 -0700 Subject: [ python-Bugs-931877 ] Segfault in object_reduce_ex Message-ID: Bugs item #931877, was opened at 2004-04-08 13:46 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Segfault in object_reduce_ex Initial Comment: Shane Hathaway bumped into this, unbounded recursion in typeobject.c's object_reduce_ex(). This occurs in Python 2.3.3 and current CVS. Assigned to Guido, to ponder whether object_reduce_ex is doing what it should; if it is (which seems likely to me), I suppose we need to inject a recursion counter to prevent the segfault. The failing case is short, but I'll attach it (temp99.py) to avoid SF line mangling. While the test uses pickle, same symptom if it's changed to use cPickle instead. Jim Fulton's analysis: """ This is a very clever infinite loop. The proxy doesn't actually proxy, but it does manage to confuse reduce about what's going on. reduce tries to figure out if it has been overridden by asking whether the class's reduce is the same as object.__reduce__. It doesn't expect to be lied to about the class. Things wouldn't have been so bad if the proxy had proxied __reduce__ as well as __class__. """ The priority hasn't been bumped, because "the real code" from which this was whittled down wasn't doing what it needed to do anyway, and the recursion went away when the real code was repaired. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-03-31 20:43 Message: Logged In: YES user_id=1326842 See patch #1462488. If that patch is accepted, this bug should be closed as fixed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 00:05 Message: Logged In: YES user_id=6380 Unassigning. I need to concentrate on Python 3000. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 16:58 Message: Logged In: YES user_id=1188172 Still crashing with 2.5... ---------------------------------------------------------------------- Comment By: Nathan Srebro (nati) Date: 2004-11-29 20:26 Message: Logged In: YES user_id=63133 This infinite recursion also occurs in another place, that got me stumped for a couple of days when old code that worked with Python 2.2 stopped working. If __class__ is not fidgeted with (as in original bug report), but a descriptor returns a custom reduce for the class, but not for its objects, reduce enters an infinite loop on the object: """ class descriptor_for_reduce(object): def __get__(self,obj,tp=None): if obj is not None: return super(ASpecialClass,obj).__reduce__ return self.reducer def reducer(self,proto=None): return "VerySpecial" class ASpecialClass(object): __reduce__ = descriptor_for_reduce() copy.copy(ASpecialClass()) """ ASpecialClass().__reduce__ is object.__reduce__, which is implemented by typeobject.c:object_reduce_ex. This function (that doesn't know if its called as the __reduce__ or the __reduce_ex__ method) tries to detect if the object's __reduce__ is overridden. It does so by checking if the object's class's __reduce__ is overridden, and in fact it is. It then assumes that the object's __reduce__ is overridden, and calls it. But the object's __reduce__ is the same function, causing the infinite loop. If __reduce_ex__ is used instead of __reduce__, the problem goes away, ASpecialClass().__reduce_ex__() return the usual tuple, and ASpecialClass.__reduce_ex__() return "VerySpecial". But when __reduce__ is overridden, ASpecialClass().__reduce__() enters an infinite loop. I believe this is a legitimate example that should behave just as when __reduce_ex__ is overridden. The example doesn't lie about __class__, and it is certainly legitimate for define a property that behaves differently for the class and for its objects. Where did this come up and why would I ever care about a class's __reduce__? The __reduce__ attribute of a class is never used by (the standard) pickle or copy, since save_global() is called instead. However, I have a custom pickler, implemented as a subclass of pickle.Pickler, which falls back on the class's __reduce__ when save_global() fails. This way, I can pickle certain classes that are created at run-time (and can be easily recreated, e.g. from their bases and dictionaries). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-04-08 13:51 Message: Logged In: YES user_id=31435 Hmm! The temp99.py download link doesn't work for me. Here's the content in case it doesn't work for others either: """ import cPickle as pickle from pickle import dumps class SimpleItem: def __reduce__(self): return (self.__class__, None, {}) class Proxy(object): __class__ = property(lambda self: self.__target.__class__) def __init__(self, target): self.__target = target def __getstate__(self): raise RuntimeError("No don't pickle me! Aaarrgghh!") p = Proxy(SimpleItem()) dumps(p) """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 From noreply at sourceforge.net Sun Apr 2 21:21:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 12:21:23 -0700 Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build Message-ID: Bugs item #1451717, was opened at 2006-03-16 23:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: OS/X on i386 framework build Initial Comment: in Makefile.pre (374) it hard codes the architecture to 'ppc' which isn't correct for the new x86 boxes. this needs to be i386 for the framework install to actually build on the new macs. regards Ian ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:21 Message: Logged In: YES user_id=580910 This is a duplicate of bug 1447587 ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2006-03-16 23:34 Message: Logged In: YES user_id=5209 also.. in plat-mac/applesingle.py the fields AS_HEADER_FORMAT and AS_ENTRY_FORMAT need a '>' infront of the definitions AS_HEADER_FORMAT=">LL16sh" AS_ENTRY_FORMAT=">lll" (this is what the system-packaged python has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 From noreply at sourceforge.net Sun Apr 2 21:24:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 12:24:47 -0700 Subject: [ python-Bugs-1445781 ] install fails on hard link Message-ID: Bugs item #1445781, was opened at 2006-03-08 18:06 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Martin v. L??wis (loewis) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:24 Message: Logged In: YES user_id=580910 Adding a -s flag to the link command should also fix this issue and has the advantage that all builds will be done the same way. The cost for resolving the symlink should be neglectible. ---------------------------------------------------------------------- Comment By: goldenautumnday (goldenautumnday) Date: 2006-03-08 21:22 Message: Logged In: YES user_id=1471082 Changing line 599 in Makefile.pre.in to: (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python $(VERSION)$(EXE) $(PYTHON)) allowed make to complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 From noreply at sourceforge.net Sun Apr 2 21:28:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 12:28:38 -0700 Subject: [ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9 Message-ID: Bugs item #1437614, was opened at 2006-02-23 19:48 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Li Quid (liquid333) Assigned to: Nobody/Anonymous (nobody) Summary: can't send files via ftp on my MacOS X 10.3.9 Initial Comment: When trying to do a simple ftp upload using Python 2.3's ftplib, it fails and I get a socket error. The exact error is (61, 'Connection refused'). This happens to me in all my scripts that use the ftplib on MacOS 10.3.9, but not in scripts on my Windows box. I've attached the small, simple source code. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:28 Message: Logged In: YES user_id=580910 I use ftplib on OSX and don't see problems (both python 2.3 and 2.4 on OSX 10.3 and 10.4). I agree with tjreedy that this is most likely a problem with the environment of the user. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 03:26 Message: Logged In: YES user_id=593130 This could be a problem in your specific machine and its setup, the specific OS version, the specific target (maybe nyx doesn't like MACs), or the specific Python version. I would start by installing 2.4.2 and see if there have maybe been helpful changes to its socket code. And try to find another Mac box. And then ask on python- list/comp.lang.python for other experiences with Max, OSX, sockets, and maybe ftp. Since the error message comes from the OS blaming nyx, I think more likely than not that this is not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 From noreply at sourceforge.net Sun Apr 2 21:41:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 12:41:21 -0700 Subject: [ python-Bugs-1447587 ] Mac Framework build fails on intel Message-ID: Bugs item #1447587, was opened at 2006-03-10 22:02 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447587&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michael Mondragon (mammon_) Assigned to: Nobody/Anonymous (nobody) Summary: Mac Framework build fails on intel Initial Comment: hardware: intel duo imac 20" os x: 10.4.6 steps: ------ ./configure --enable-framework=/Library/Frameworks/Python.framework --enable-shared make ... c++ -u _PyMac_Error Python.framework/Versions/2.4/Python -o python.exe \ Modules/python.o \ -ldl /usr/bin/ld: warning Python.framework/Versions/2.4/Python cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: _PyMac_Error _Py_Main collect2: ld returned 1 exit status make: *** [python.exe] Error 1 analysis: --------- The arch flag for the Python shared library in the framework is incorrect. file shows Python.framework/Versions/2.4/Python to be a PPC binary. scroll up in terminal to find link statement for Python: libtool -o Python.framework/Versions/2.4/Python -dynamic libpython2.4.a \ -lSystem -lSystemStubs -arch_only ppc -install_name /Library/Frameworks/Python.framework/Python.framework/Versions/2.4/Python -compatibility_version 2.4 -current_version 2.4 The '-arch_only ppc' flag is the problem. workaround: ----------- After running configure, open makefile and so a s/arch_only ppc/arch_only i386/g what needs to be fixed: ----------------------- Around line 10218 in configure: Darwin/[01234567].*) LIBTOOL_CRUFT="-framework System -lcc_dynamic -arch_only ppc" LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -install_name $(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)' LIBTOOL_CRUFT=$LIBTOOL_CRUFT' -compatibility_version $(VERSION) -current_version $(VERSION)';; Darwin/*) gcc_version=`gcc -v 2>&1 | grep version | cut -d\ -f3` if test ${gcc_version} '<' 4.0 then LIBTOOL_CRUFT="-lcc_dynamic" else LIBTOOL_CRUFT="" fi ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-02 19:41 Message: Logged In: YES user_id=849994 Duplicate of #1451717. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447587&group_id=5470 From noreply at sourceforge.net Sun Apr 2 22:37:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 13:37:32 -0700 Subject: [ python-Bugs-1462706 ] urllib2 bails if the localhost doens't have a fqdn hostname Message-ID: Bugs item #1462706, was opened at 2006-04-01 15:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 Please note that this 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 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 bails if the localhost doens't have a fqdn hostname Initial Comment: When running the test suite I ran into a similar problem to bug #1257988. in the FileHandler class's get_names() method should be wrapped in a try, except block because it shouldn't assume that the localhost has a fqdn hostname. Attached is a minimal diff against trunk r43542. Matt ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-02 20:37 Message: Logged In: YES user_id=849994 Fixed in rev. 43552. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 22:35 Message: Logged In: YES user_id=261020 This fixes the test failure and is safe. I don't know if a more sophisticated patch is possible, but if nobody comes up with one, I think this should be applied (as happened with #1257988). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 From noreply at sourceforge.net Mon Apr 3 07:30:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 22:30:15 -0700 Subject: [ python-Bugs-1462700 ] Errors in PCbuild Message-ID: Bugs item #1462700, was opened at 2006-04-01 17:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Martin v. L??wis (loewis) Summary: Errors in PCbuild Initial Comment: pcbuild.sln: pythoncore has a different GUID to pythoncore.vsproj. _ctypes_test needs to be dependent on _ctypes. Diff attached. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 07:30 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as 43569. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 From noreply at sourceforge.net Mon Apr 3 07:37:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Apr 2006 22:37:14 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 07:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-02 22:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 07:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Mon Apr 3 09:30:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 00:30:39 -0700 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this 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: AST Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 00:30 Message: Logged In: YES user_id=33168 The tuple store problem is fixed. The only outstanding item is the LOAD_CONST/POP_TOP. I will fix that soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-17 22:56 Message: Logged In: YES user_id=33168 Jeremy, there's no need to read anything before my last comment at 2005-12-17 23:10. The last two by Armin, Michael, then my last comment are the only important ones. Everything that occurred before my 2005-12-17 comment was taken care of AFAIK. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-02-12 13:54 Message: Logged In: YES user_id=4771 Subscripting is generally a bit sloppy: e.g. the AST model has no way to distinguish between a single value and a one-element tuple value! See: >>> d = {} >>> d[1,] = 6 >>> d {1: 6} # ! I suggest we fix the model to turn the 'subs' of the 'Subscript' node from a list of nodes to a single, mandatory 'sub' node. If tupling is necessary, it can be explicitly represented with a 'sub' containing a 'Tuple' node. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-09 07:02 Message: Logged In: YES user_id=6656 We found another one. Something is wrong in the compilation of augmented assignment to subscriptions containing tuples; running this code: class C: def __setitem__(self, i, v): print i, v def __getitem__(self, i): print i return 0 c = C() c[4,5] += 1 gives a spurious exception: Traceback (most recent call last): File "", line 1, in TypeError: object does not support item assignment By contrast, "c[(4,5)] += 1" works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 23:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 16:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 15:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 02:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 12:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 21:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 00:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Mon Apr 3 12:57:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 03:57:36 -0700 Subject: [ python-Bugs-1421664 ] [win32] stderr atty encoding not set Message-ID: Bugs item #1421664, was opened at 2006-02-01 18:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470 Please note that this 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: 6 Submitted By: Snaury (snaury) Assigned to: Martin v. L??wis (loewis) Summary: [win32] stderr atty encoding not set Initial Comment: When starting python console application under windows, output of unicode strings to console fails because of ansi encoding. I found that in file Python-2.4.2/Python/sysmodule, _PySys_Init functions, setting encoding on stderr was forgotten: #ifdef MS_WINDOWS if(isatty(_fileno(stdin))){ sprintf(buf, "cp%d", GetConsoleCP()); if (!PyFile_SetEncoding(sysin, buf)) return NULL; } if(isatty(_fileno(stdout))) { sprintf(buf, "cp%d", GetConsoleOutputCP()); if (!PyFile_SetEncoding(sysout, buf)) return NULL; } #endif I think the following lines should be added: if(isatty(_fileno(stderr))) { sprintf(buf, "cp%d", GetConsoleOutputCP()); if (!PyFile_SetEncoding(syserr, buf)) return NULL; } Otherwise it's inconsistant, as if we set it to sysout, why not on syserr? And, for example, this code will not work properly: #!/usr/bin/env python # -*- encoding: mbcs -*- import sys reload(sys) # bring setdefaultencoding back! sys.setdefaultencoding("mbcs") sys.stderr.write(u"\n") Instead of native text garbage will be printed (if you change it to sys.stdout, proper text displayed), and there is no way I know to properly determine and set encoding just for stderr (file.encoding is read-only, after all). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 12:57 Message: Logged In: YES user_id=21627 Thanks for the report. This is now fixed in #43581. ---------------------------------------------------------------------- Comment By: Snaury (snaury) Date: 2006-02-01 18:29 Message: Logged In: YES user_id=1197042 Ooops, sorry, in the example it should be: print >>sys.stderr, u"" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470 From noreply at sourceforge.net Mon Apr 3 13:38:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 04:38:29 -0700 Subject: [ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed Message-ID: Bugs item #1456470, was opened at 2006-03-22 23:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 Please note that this 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: Fixed Priority: 6 Submitted By: Jim Jewett (jimjjewett) Assigned to: Martin v. L??wis (loewis) Summary: sliceobject ssize_t (and index) not completed Initial Comment: sliceobject and ceval changed the parameter types of slice objects to ssize_t, but the code still requires an int (sometimes not even a long); it should use the new __index__ slot; at the very least, it should be consistent about what it does accept. In http://svn.python.org/view/python/trunk/Objects/ sliceobject.c?rev=42382&view=markup [issue 1] function PySlice_GetIndices takes Py_ssize_t parameters for (length, start, stop, step) but then does a PyInt_Check on each of start, stop, step. (An XXX to allow longs was also removed.) It * should* use the new __index__ slot. [issue 2] Later in the same file, function slice_ indices takes a PyObject len parameter, but then uses PyInt_AsLong rather than __index__ (or even PyInt_ AsSsize_t) to create Py_ssize_t ilen. [issue 3] http://svn.python.org/view/python/trunk/Python/ceval.c? rev=42382&view=markup function _PyEval_SliceIndex accepts only ints and longs, and longs will be converted to ints with clipping. It should allow anything with __index__, and clip only to ssize_t rather than int. [issue 4] ISINT still insists on int or long -- I thought I saw a fix for this already in the index patches. [issue 5] apply_slice and assign_slice changed the types of ilow and ihigh, but still initializes them to INT_MAX rather than ssize_t max. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 13:38 Message: Logged In: YES user_id=21627 I believe these are all fixed as of 43583 (and earlier). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-24 09:33 Message: Logged In: YES user_id=21627 Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 From noreply at sourceforge.net Mon Apr 3 14:18:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 05:18:57 -0700 Subject: [ python-Bugs-1461115 ] test_winsound fails in 2.4.3 Message-ID: Bugs item #1461115, was opened at 2006-03-30 07:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 Please note that this 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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. L??wis (loewis) Summary: test_winsound fails in 2.4.3 Initial Comment: The released 2.4.3 Windows installer doesn't include source file Lib/test/check_soundcard.vbs, which causes test_winsound to report 7 bogus failures when run on a box with a sound card. I expect the 2.5 installer also needs to be fiddled to include this file. I confirmed that the problem went away after copying check_soundcard.vbs from a 2.4 branch checkout into the 2.4.3 installation tree. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 14:18 Message: Logged In: YES user_id=21627 Thanks for the report; this was fixed in 43584 and 43585. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 From noreply at sourceforge.net Mon Apr 3 14:21:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 05:21:20 -0700 Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames Message-ID: Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 Please note that this 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.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) >Assigned to: Georg Brandl (gbrandl) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 14:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. ---------------------------------------------------------------------- Comment By: roee88 (roee88) Date: 2006-03-22 13:00 Message: Logged In: YES user_id=1111143 Sorry, but I can't work on a patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 From noreply at sourceforge.net Mon Apr 3 14:26:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 05:26:46 -0700 Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames Message-ID: Bugs item #1451503, was opened at 2006-03-16 18:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 Please note that this 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.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) Assigned to: Georg Brandl (gbrandl) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-03 12:26 Message: Logged In: YES user_id=849994 Rev. 43586. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 12:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 15:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. ---------------------------------------------------------------------- Comment By: roee88 (roee88) Date: 2006-03-22 12:00 Message: Logged In: YES user_id=1111143 Sorry, but I can't work on a patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 10:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 From noreply at sourceforge.net Mon Apr 3 14:33:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 05:33:46 -0700 Subject: [ python-Bugs-1445781 ] install fails on hard link Message-ID: Bugs item #1445781, was opened at 2006-03-08 18:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Martin v. L??wis (loewis) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 14:33 Message: Logged In: YES user_id=21627 If we are going to support "funny" file systems, falling back to copying looks right to me. While Apple's SMB implementation supports symlinks on smb (through a hack), other implementations might not. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:24 Message: Logged In: YES user_id=580910 Adding a -s flag to the link command should also fix this issue and has the advantage that all builds will be done the same way. The cost for resolving the symlink should be neglectible. ---------------------------------------------------------------------- Comment By: goldenautumnday (goldenautumnday) Date: 2006-03-08 21:22 Message: Logged In: YES user_id=1471082 Changing line 599 in Makefile.pre.in to: (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python $(VERSION)$(EXE) $(PYTHON)) allowed make to complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 From noreply at sourceforge.net Mon Apr 3 14:57:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 05:57:28 -0700 Subject: [ python-Feature Requests-1451588 ] bisect should support a custom comparison function Message-ID: Feature Requests item #1451588, was opened at 2006-03-16 19:26 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1451588&group_id=5470 Please note that this 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 Submitted By: Jonathan S. Joseph (jsjoseph) Assigned to: Nobody/Anonymous (nobody) Summary: bisect should support a custom comparison function Initial Comment: The 'bisect' module provides functions for finding the proper insertion point of an item in a sorted list. The sort() function for lists supports passing in a custom comparison function, however none of the functions in bisect() support this. The method used by bisect to find the proper insertion point is not documented, but I guess the module relies on a natural ordering for the items, or on the items of the list implementing __cmp__. I suggest adding a 5th argument, with keyword 'cmp', to the functions in the 'bisect' module that would allow supplying a custom comparison function, as for 'sort'. bisect_left( list, item[, lo[, hi]][,cmp]) bisect_right( list, item[, lo[, hi]][,cmp]) bisect(...) insort_left( list, item[, lo[, hi]][,cmp]) insort_right( list, item[, lo[, hi]][,cmp]) insort(...) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-03 12:57 Message: Logged In: YES user_id=1126061 See patch #1462228. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1451588&group_id=5470 From noreply at sourceforge.net Mon Apr 3 15:37:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 06:37:52 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 15:03 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-03 14:37 Message: Logged In: YES user_id=200117 Hi Neal, I've just built 2.4.3 on a Red Hat Enterpeise Edition WS V4.2 machine and this gives the same error. I've had this vague feeling that I've seen something like this before, but couldn't find anything when I searched the tracker... I've now realised that the error is due to a conflict with PyXML-0.8.4 which was already installed on both machines. If I rename the ../site_packages/_xmlplus directory to a different name then the error goes away (on the Red Hat machine at least, the SUSE machine is at home). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 06:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 15:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Mon Apr 3 16:04:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 07:04:02 -0700 Subject: [ python-Bugs-1463559 ] missing svnversion == configure error Message-ID: Bugs item #1463559, was opened at 2006-04-04 00: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=1463559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: missing svnversion == configure error Initial Comment: Attempting to build the trunk from source on a box without svn installed spits this out of configure: checking for svnversion... no ./configure: line 3616: test: =: unary operator expected We should handle this more gracefully. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463559&group_id=5470 From noreply at sourceforge.net Mon Apr 3 17:31:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 08:31:23 -0700 Subject: [ python-Bugs-1191458 ] [AST] Failing tests Message-ID: Bugs item #1191458, was opened at 2005-04-28 03:30 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 Please note that this 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: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jeremy Hylton (jhylton) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 15:31 Message: Logged In: YES user_id=31392 Just wanted to note that I have fixes for the failing tests on my laptop. Need to sync with the current trunk before I can check in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-10-25 22:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-24 04:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 11:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 08:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 From noreply at sourceforge.net Mon Apr 3 17:44:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 08:44:36 -0700 Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly Message-ID: Bugs item #1153622, was opened at 2005-02-28 16:48 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Jeremy Hylton (jhylton) Summary: eval does not bind variables in lambda bodies correctly Initial Comment: eval() does not bind variables in lambda expressions correctly: >>>def f(g): return eval('lambda x: g(x)') >>>f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in NameError: global name 'g' is not defined The docs say this about eval(): # If both dictionaries are omitted, the expression is # executed in the environment where eval is called. and using plain local variables work as expected: >>>def h(d): return eval('d(10)') >>>h(lambda y: y * 2) 20 Also, if locals() is presented as the global dict to eval(), it works: >>>def f(g): return eval('lambda x: g(x)', locals(), locals()) >>>f(lambda y: y * 2)(17) 34 but this does not allow the expression to reference global variables of course. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 15:44 Message: Logged In: YES user_id=31392 The source of the problem is that scoping decisions are made statically. If a variable is determined to be local at compile time, it can't be access as a free variable in dynamically compiled code. The compiler has already determined that the variable is *not* free in the containing function. If a variable is free in a nested function, the compiler treats it differently than if it is merely local to the function. In the most recent cases considered, def f(x): eval('x') -- works because x is a local variable in f. def f(g): eval('lambda x: g(x)') -- does not work because the compiler has determined that g is not used a free variable in f. It isn't possible to change that static analysis at runtime using eval or exec. I agree that the documentation could be clearer here. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 03:46 Message: Logged In: YES user_id=593130 " def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why?" For the same reason def f(g,s): return eval(s) f(lambda x: x, 'lambda x: g(x)')(1) and def g(x): return lambda: eval('x') do not 'work'. eval is a builtin C function whose behavior depends on its arguments (including the somewhat magical defaulting to globals(), local()) and not on its lexical position. " Both are evaluated at the same time and use the same environment to look up their variables." No, the lambda in your second example introduces a new local namespace that is different from the one passed in. " The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping" The delay and change of scoping are correlated. Evaluation is delayed because g is inside a lambda function def which introduces a new local scope which does not contain g, even though the original one did. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 02:55 Message: Logged In: YES user_id=593130 After more carefully reading the eval doc in Lib Ref 2.1, I agree that it needs improvement. My suggestions (assuming that my experiment-based inferences are correct): In "The expression argument is parsed and evaluated as a Python expression (technically speaking, a condition list) using the globals and locals dictionaries as global and local name space." insert "in a new top-level environment" before 'using'. This says right-off, even if indirectly, that lexical scoping does not work across the eval call. In "If the locals dictionary is omitted it defaults to the globals dictionary." insert "only" after "If'. If both are omitted, it does not so default. Add a comma after 'omitted', as in the next sentence. In "If both dictionaries are omitted, the expression is executed in the environment where eval is called." replace "the expression ... is called", which I believe to be incorrect as well as misleading, with something like "they default to current globals() and locals()." This parallels the previous sentence and is, I believe, more correct. Within a function, locals() is not the current local namespace, and the following shows that the difference can make a visible difference: >>> def g1(): return op.setitem(locals(), 'x', 1), x ... >>> g1() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in g1 NameError: global name 'x' is not defined >>> def h1(): return eval("op.setitem(locals(), 'x', 1), x") ... >>> h1() (None, 1) After "The return value is the result of the evaluated expression. " add something like It does not depend on the lexical position of the eval call and hence the expression should not contain names that require lexical scoping reaching outside the eval call to be valid." Note that eval scope blocking, the OP's pseudobug, does not require a lambda within the eval-ed expression: >>> def f(x): return lambda: x ... >>> f(1)() 1 >>> def g(x): return lambda: eval('x') ... >>> g(1)() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in File "", line 0, in ? NameError: name 'x' is not defined This might be another example for the PEP. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-03 15:29 Message: Logged In: YES user_id=80475 Jeremy, would you update the pep and docs to cover the OP's examples. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-03 11:16 Message: Logged In: YES user_id=432579 >No, this issue is not specific to either eval or lambda: Right, so let me rephrase: The bug occurs when explicitly evaluating a lambda expression or function definition statement using eval or exec. (This is an artifact of Python's strong separation of statements and expressions.) If this is done "by design", why cannot I find anything anywhere describing this? If this is just a documentation oversight, please say so, but then I would also like to have an explanation of the behaviour. The fact remains that def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why? Both are evaluated at the same time and use the same environment to look up their variables. The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping, because that is how lambda expressions work. >If you want Python to work >differently, write a PEP or a patch, or raise the question in >the newsgroup/mailing list. www.python.org told me that this is the place to report bugs in Python. If that is wrong, we should change the web site. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-02 22:59 Message: Logged In: YES user_id=593130 No, this issue is not specific to either eval or lambda: >>> def f(g): ... exec 'def h(x): return g(x)' ... return h ... >>> f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in h NameError: global name 'g' is not defined It is specific to creating a function at top-level in a separate execution environment, as done, by design, by both eval and exec, and with either a def statement or lambda abbreviation thereof. In Python, lexical scoping works because nested functions are compiled along with the outer function, so that scoped variables can be identified and both functions adjusted so that the coupling works. In particular, the scoped variable has to not be deleted when the outer function returns. Eval/exec compile their string only later, when the function is called. "it works that way because it is the way it works". Those are your words, not mine. If you want Python to work differently, write a PEP or a patch, or raise the question in the newsgroup/mailing list. I'm done discussing it here. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-02 16:42 Message: Logged In: YES user_id=432579 No, this issue is specific to eval of lambda expressions. Please read my problem description. Please refer to the Python documentation if you are confused with how standard function declaration or lexical scoping works. ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 00:20 Message: Logged In: YES user_id=1230541 Obviously I forgot a statement in my previous comment's code example. So here's the complete version: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again n=3 f(2) # the implementation will return 6, but how about your expected implementation? ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 00:15 Message: Logged In: YES user_id=1230541 I think this issue is not special for eval and can be also reproduced with a def statement. The point is that at function definition time Python does not do any variable binding concerning variables not local to the function. Instead Python looks for that variable in the namespace of the module in which the function was created at the time the function is executed. Python determines that module by evaluating the variable __module__ at function definition time and remembers it by setting the function attribute with the same name. That's why only the variable __module__ is relevant at function definition time. Simply put, Python does only do a module level variable binding at function definition time. This is simple and sensible. If you don't agree consider this: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again f(2) # the implementation will return 6, but how about your expected implementation? As you see, changing the implementation would either make Pythons semantics more complicated or would remove much of Pythons dynanism. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 18:26 Message: Logged In: YES user_id=432579 What you are saying is "it works that way because it is the way it works". I see no reason at all for this odd behaviour other than bug-compatibility. I find nothing at all in the documentation supporting this behaviour either; please inform me if I have missed something. All other languages supporting eval and lexical scoping (Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I have no problems if Python wants to be different for whatever reason, but it should be documented. I did a quick Google in comp.lang.python but could not find anything that supported this "exception" or gave a rational explanation. Kindly direct me to any resource you know of that could help enlighten me on this issue. ># From your comments, I suspect you expect 0. Of course not. I know very well how lexical scoping works, so please don't put words in my mouth. None of your examples have anything to do with scoping. As we both know, it is not the _values_ of the variables that is important for variable binding, it is their identity; which variable is chosen, not what they happen to contain at the time the lambda expression is evaluated. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 17:29 Message: Logged In: YES user_id=593130 Whoops. eval('x') == x as code snippets has an exception, which is the one tripping you up. When the eval is within a function definition (and lambda expressions are abbreviated simple function definitions) and 'x' contains a function definition, then the body of the contained function definition does not have access, when it is run, to the locals of the containing function (the lexical scope), whereas it will when x is compiled directly *as part of the containing function body*. eval('x') removes x from that part of its context. eval only has the simple two-level globals/locals environment, which can be anything the caller passes in, so it compiles x as if it were top-level code. Hence free variables in contained functions are looked up in the global passed to eval when the evaled function is called. This issue has been discussed on the Python newsgroup/mailing list more than once. If my explanation is not clear, you might be able to find others in Google c.l.p archives. Do consider that core functions which have been debugged for over a decade are unlike to have many bugs left, although the docs are still being improved. While Python's scoping is lexical, its free variable binding is late. Consider >>> def f(): ... x = 0 ... def g(): print x ... x = 1 ... return g ... >>> f()() # What gets printed? 0 or 1? # From your comments, I suspect you expect 0. # Irregardless, it is 1 Similarly >>> f()() 1 >>> d={'x': 0} >>> h=eval('lambda: x', d, d) >>> h() 0 >>> d['x'] = 1 >>> h() # now what gets printed? 1 ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 09:11 Message: Logged In: YES user_id=432579 >Variables in Python functions are resolved >when the function is *called*, not when it is defined. I'm not sure what you mean by that, since Python obeys lexical scoping, not dynamic.Consider: def f(x): lambda y: x + y When the inner lambda expression above is evaluated, x inside the lambda body is bound to the parameter of the call of f, even if x+y is not evaluated until that function is called. So since def f(x): return eval('x') fetches its definition of x from the lexical variable x, why shouldn't def f(g): return eval('lambda x: g(x)') fetch its definition of g from the lexical variable g? A lambda expression is just a way of delaying evaluation, *not* delaying how variables are bound --- this is done immediately. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 05:30 Message: Logged In: YES user_id=593130 I am 99.5% sure that this is 'invalid' (a Resolution category) and should be closed. With the default environment, eval('x') is the same as unquoted x. Variables in Python functions are resolved when the function is *called*, not when it is defined. There is no resolution for g in the default globals. Eval does not change this. The NameError is exactly correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 From noreply at sourceforge.net Mon Apr 3 17:45:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 08:45:21 -0700 Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly Message-ID: Bugs item #1153622, was opened at 2005-02-28 16:48 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 Please note that this 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.4 Status: Open Resolution: None >Priority: 6 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Jeremy Hylton (jhylton) Summary: eval does not bind variables in lambda bodies correctly Initial Comment: eval() does not bind variables in lambda expressions correctly: >>>def f(g): return eval('lambda x: g(x)') >>>f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in NameError: global name 'g' is not defined The docs say this about eval(): # If both dictionaries are omitted, the expression is # executed in the environment where eval is called. and using plain local variables work as expected: >>>def h(d): return eval('d(10)') >>>h(lambda y: y * 2) 20 Also, if locals() is presented as the global dict to eval(), it works: >>>def f(g): return eval('lambda x: g(x)', locals(), locals()) >>>f(lambda y: y * 2)(17) 34 but this does not allow the expression to reference global variables of course. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 15:44 Message: Logged In: YES user_id=31392 The source of the problem is that scoping decisions are made statically. If a variable is determined to be local at compile time, it can't be access as a free variable in dynamically compiled code. The compiler has already determined that the variable is *not* free in the containing function. If a variable is free in a nested function, the compiler treats it differently than if it is merely local to the function. In the most recent cases considered, def f(x): eval('x') -- works because x is a local variable in f. def f(g): eval('lambda x: g(x)') -- does not work because the compiler has determined that g is not used a free variable in f. It isn't possible to change that static analysis at runtime using eval or exec. I agree that the documentation could be clearer here. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 03:46 Message: Logged In: YES user_id=593130 " def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why?" For the same reason def f(g,s): return eval(s) f(lambda x: x, 'lambda x: g(x)')(1) and def g(x): return lambda: eval('x') do not 'work'. eval is a builtin C function whose behavior depends on its arguments (including the somewhat magical defaulting to globals(), local()) and not on its lexical position. " Both are evaluated at the same time and use the same environment to look up their variables." No, the lambda in your second example introduces a new local namespace that is different from the one passed in. " The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping" The delay and change of scoping are correlated. Evaluation is delayed because g is inside a lambda function def which introduces a new local scope which does not contain g, even though the original one did. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 02:55 Message: Logged In: YES user_id=593130 After more carefully reading the eval doc in Lib Ref 2.1, I agree that it needs improvement. My suggestions (assuming that my experiment-based inferences are correct): In "The expression argument is parsed and evaluated as a Python expression (technically speaking, a condition list) using the globals and locals dictionaries as global and local name space." insert "in a new top-level environment" before 'using'. This says right-off, even if indirectly, that lexical scoping does not work across the eval call. In "If the locals dictionary is omitted it defaults to the globals dictionary." insert "only" after "If'. If both are omitted, it does not so default. Add a comma after 'omitted', as in the next sentence. In "If both dictionaries are omitted, the expression is executed in the environment where eval is called." replace "the expression ... is called", which I believe to be incorrect as well as misleading, with something like "they default to current globals() and locals()." This parallels the previous sentence and is, I believe, more correct. Within a function, locals() is not the current local namespace, and the following shows that the difference can make a visible difference: >>> def g1(): return op.setitem(locals(), 'x', 1), x ... >>> g1() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in g1 NameError: global name 'x' is not defined >>> def h1(): return eval("op.setitem(locals(), 'x', 1), x") ... >>> h1() (None, 1) After "The return value is the result of the evaluated expression. " add something like It does not depend on the lexical position of the eval call and hence the expression should not contain names that require lexical scoping reaching outside the eval call to be valid." Note that eval scope blocking, the OP's pseudobug, does not require a lambda within the eval-ed expression: >>> def f(x): return lambda: x ... >>> f(1)() 1 >>> def g(x): return lambda: eval('x') ... >>> g(1)() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in File "", line 0, in ? NameError: name 'x' is not defined This might be another example for the PEP. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-03 15:29 Message: Logged In: YES user_id=80475 Jeremy, would you update the pep and docs to cover the OP's examples. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-03 11:16 Message: Logged In: YES user_id=432579 >No, this issue is not specific to either eval or lambda: Right, so let me rephrase: The bug occurs when explicitly evaluating a lambda expression or function definition statement using eval or exec. (This is an artifact of Python's strong separation of statements and expressions.) If this is done "by design", why cannot I find anything anywhere describing this? If this is just a documentation oversight, please say so, but then I would also like to have an explanation of the behaviour. The fact remains that def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why? Both are evaluated at the same time and use the same environment to look up their variables. The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping, because that is how lambda expressions work. >If you want Python to work >differently, write a PEP or a patch, or raise the question in >the newsgroup/mailing list. www.python.org told me that this is the place to report bugs in Python. If that is wrong, we should change the web site. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-02 22:59 Message: Logged In: YES user_id=593130 No, this issue is not specific to either eval or lambda: >>> def f(g): ... exec 'def h(x): return g(x)' ... return h ... >>> f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in h NameError: global name 'g' is not defined It is specific to creating a function at top-level in a separate execution environment, as done, by design, by both eval and exec, and with either a def statement or lambda abbreviation thereof. In Python, lexical scoping works because nested functions are compiled along with the outer function, so that scoped variables can be identified and both functions adjusted so that the coupling works. In particular, the scoped variable has to not be deleted when the outer function returns. Eval/exec compile their string only later, when the function is called. "it works that way because it is the way it works". Those are your words, not mine. If you want Python to work differently, write a PEP or a patch, or raise the question in the newsgroup/mailing list. I'm done discussing it here. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-02 16:42 Message: Logged In: YES user_id=432579 No, this issue is specific to eval of lambda expressions. Please read my problem description. Please refer to the Python documentation if you are confused with how standard function declaration or lexical scoping works. ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 00:20 Message: Logged In: YES user_id=1230541 Obviously I forgot a statement in my previous comment's code example. So here's the complete version: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again n=3 f(2) # the implementation will return 6, but how about your expected implementation? ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 00:15 Message: Logged In: YES user_id=1230541 I think this issue is not special for eval and can be also reproduced with a def statement. The point is that at function definition time Python does not do any variable binding concerning variables not local to the function. Instead Python looks for that variable in the namespace of the module in which the function was created at the time the function is executed. Python determines that module by evaluating the variable __module__ at function definition time and remembers it by setting the function attribute with the same name. That's why only the variable __module__ is relevant at function definition time. Simply put, Python does only do a module level variable binding at function definition time. This is simple and sensible. If you don't agree consider this: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again f(2) # the implementation will return 6, but how about your expected implementation? As you see, changing the implementation would either make Pythons semantics more complicated or would remove much of Pythons dynanism. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 18:26 Message: Logged In: YES user_id=432579 What you are saying is "it works that way because it is the way it works". I see no reason at all for this odd behaviour other than bug-compatibility. I find nothing at all in the documentation supporting this behaviour either; please inform me if I have missed something. All other languages supporting eval and lexical scoping (Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I have no problems if Python wants to be different for whatever reason, but it should be documented. I did a quick Google in comp.lang.python but could not find anything that supported this "exception" or gave a rational explanation. Kindly direct me to any resource you know of that could help enlighten me on this issue. ># From your comments, I suspect you expect 0. Of course not. I know very well how lexical scoping works, so please don't put words in my mouth. None of your examples have anything to do with scoping. As we both know, it is not the _values_ of the variables that is important for variable binding, it is their identity; which variable is chosen, not what they happen to contain at the time the lambda expression is evaluated. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 17:29 Message: Logged In: YES user_id=593130 Whoops. eval('x') == x as code snippets has an exception, which is the one tripping you up. When the eval is within a function definition (and lambda expressions are abbreviated simple function definitions) and 'x' contains a function definition, then the body of the contained function definition does not have access, when it is run, to the locals of the containing function (the lexical scope), whereas it will when x is compiled directly *as part of the containing function body*. eval('x') removes x from that part of its context. eval only has the simple two-level globals/locals environment, which can be anything the caller passes in, so it compiles x as if it were top-level code. Hence free variables in contained functions are looked up in the global passed to eval when the evaled function is called. This issue has been discussed on the Python newsgroup/mailing list more than once. If my explanation is not clear, you might be able to find others in Google c.l.p archives. Do consider that core functions which have been debugged for over a decade are unlike to have many bugs left, although the docs are still being improved. While Python's scoping is lexical, its free variable binding is late. Consider >>> def f(): ... x = 0 ... def g(): print x ... x = 1 ... return g ... >>> f()() # What gets printed? 0 or 1? # From your comments, I suspect you expect 0. # Irregardless, it is 1 Similarly >>> f()() 1 >>> d={'x': 0} >>> h=eval('lambda: x', d, d) >>> h() 0 >>> d['x'] = 1 >>> h() # now what gets printed? 1 ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 09:11 Message: Logged In: YES user_id=432579 >Variables in Python functions are resolved >when the function is *called*, not when it is defined. I'm not sure what you mean by that, since Python obeys lexical scoping, not dynamic.Consider: def f(x): lambda y: x + y When the inner lambda expression above is evaluated, x inside the lambda body is bound to the parameter of the call of f, even if x+y is not evaluated until that function is called. So since def f(x): return eval('x') fetches its definition of x from the lexical variable x, why shouldn't def f(g): return eval('lambda x: g(x)') fetch its definition of g from the lexical variable g? A lambda expression is just a way of delaying evaluation, *not* delaying how variables are bound --- this is done immediately. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 05:30 Message: Logged In: YES user_id=593130 I am 99.5% sure that this is 'invalid' (a Resolution category) and should be closed. With the default environment, eval('x') is the same as unquoted x. Variables in Python functions are resolved when the function is *called*, not when it is defined. There is no resolution for g in the default globals. Eval does not change this. The NameError is exactly correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 From noreply at sourceforge.net Mon Apr 3 18:50:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 09:50:40 -0700 Subject: [ python-Bugs-1431582 ] long path support in win32 part of os.listdir(posixmodule.c) Message-ID: Bugs item #1431582, was opened at 2006-02-14 16:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None >Priority: 7 Submitted By: Sergey Dorofeev (fidoman) Assigned to: Martin v. L??wis (loewis) Summary: long path support in win32 part of os.listdir(posixmodule.c) Initial Comment: When passing path to os.listdir that is longer then MAX_PATH (what is supported in Windows API, http://msdn.microsoft.com/library/default.asp? url=/library/en-us/fileio/fs/naming_a_file.asp) the path is truncated at position MAX_PATH=260 and appended with "/*.*", so underlying Windows API function FindFirstFileW gets garbage on input: original path truncated, and symbol "/" is added, which may not be used as path separator in long path. I think posix_listdir should or raise error when getting extra long string, or pass it unchanged to underlying API. Affected code is in Modules\posixmodule.c, lines 1470- 1478 (Python 2.4.2). I think there is enough to change base when calculating size of allocated memory and copied block from fixed value of MAX_PATH to length of passed to function string. And use os.sep instead of "/", of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470 From noreply at sourceforge.net Mon Apr 3 19:12:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 10:12:25 -0700 Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly Message-ID: Bugs item #1153622, was opened at 2005-02-28 17:48 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 6 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Jeremy Hylton (jhylton) Summary: eval does not bind variables in lambda bodies correctly Initial Comment: eval() does not bind variables in lambda expressions correctly: >>>def f(g): return eval('lambda x: g(x)') >>>f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in NameError: global name 'g' is not defined The docs say this about eval(): # If both dictionaries are omitted, the expression is # executed in the environment where eval is called. and using plain local variables work as expected: >>>def h(d): return eval('d(10)') >>>h(lambda y: y * 2) 20 Also, if locals() is presented as the global dict to eval(), it works: >>>def f(g): return eval('lambda x: g(x)', locals(), locals()) >>>f(lambda y: y * 2)(17) 34 but this does not allow the expression to reference global variables of course. ---------------------------------------------------------------------- >Comment By: Mattias Engdeg?rd (yorick) Date: 2006-04-03 19:12 Message: Logged In: YES user_id=432579 >The source of the problem is that scoping decisions are made >statically. No, because other languages with lexical scope and permitting evaluation at runtime have no problem whatsoever with this. They just answer the question: Q: In what environment is the eval() argument evaluated? typically in one of three ways: A1. In an empty environment with no bindings at all, or just the language-defined standard bindings. A2. In the (or a) top-level environment; local, lexically bound variables where the eval() takes place are not visible to the argument expression. A3. In the same lexical environment as the eval() call itself. Perl and Ruby both say A3. Scheme (R5RS) lets the user specify A1 or A2. Common Lisp answers A2. Observe that none of the answers depend on what the expression looks like. Now, let's be crystal clear about this: The rules of where x is looked up in the expressions 1) x and 2) lambda: x should reasonably be the same - after all, this is fundamentally how lexical scoping works. And Python does indeed work this way, to everybody's satisfaction. In case 2), the evaluation of x is delayed, but that is irrelevant; the decision of what x means is taken at the same time in both cases, and the decision will be the same. Most people would expect Python to answer question Q above with one of the answers A1-3, but it does not, and it does not document what the answer is. The Python answer is rather: A4. A mixed hybrid environment of some kind: The identifiers representing variables that are to be evaluated immediately are looked up in the lexical environment of the eval expression; identifiers representing variables in delayed-evaluation positions use the global environment. This answer is not very satisfactory and I'm inclined to consider a design bug; it is different from what everyone else does and not very intuitive. However, I can accept that it is hard to change now for compatibility reasons. But this answer A4 should be documented. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 17:44 Message: Logged In: YES user_id=31392 The source of the problem is that scoping decisions are made statically. If a variable is determined to be local at compile time, it can't be access as a free variable in dynamically compiled code. The compiler has already determined that the variable is *not* free in the containing function. If a variable is free in a nested function, the compiler treats it differently than if it is merely local to the function. In the most recent cases considered, def f(x): eval('x') -- works because x is a local variable in f. def f(g): eval('lambda x: g(x)') -- does not work because the compiler has determined that g is not used a free variable in f. It isn't possible to change that static analysis at runtime using eval or exec. I agree that the documentation could be clearer here. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 04:46 Message: Logged In: YES user_id=593130 " def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why?" For the same reason def f(g,s): return eval(s) f(lambda x: x, 'lambda x: g(x)')(1) and def g(x): return lambda: eval('x') do not 'work'. eval is a builtin C function whose behavior depends on its arguments (including the somewhat magical defaulting to globals(), local()) and not on its lexical position. " Both are evaluated at the same time and use the same environment to look up their variables." No, the lambda in your second example introduces a new local namespace that is different from the one passed in. " The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping" The delay and change of scoping are correlated. Evaluation is delayed because g is inside a lambda function def which introduces a new local scope which does not contain g, even though the original one did. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 03:55 Message: Logged In: YES user_id=593130 After more carefully reading the eval doc in Lib Ref 2.1, I agree that it needs improvement. My suggestions (assuming that my experiment-based inferences are correct): In "The expression argument is parsed and evaluated as a Python expression (technically speaking, a condition list) using the globals and locals dictionaries as global and local name space." insert "in a new top-level environment" before 'using'. This says right-off, even if indirectly, that lexical scoping does not work across the eval call. In "If the locals dictionary is omitted it defaults to the globals dictionary." insert "only" after "If'. If both are omitted, it does not so default. Add a comma after 'omitted', as in the next sentence. In "If both dictionaries are omitted, the expression is executed in the environment where eval is called." replace "the expression ... is called", which I believe to be incorrect as well as misleading, with something like "they default to current globals() and locals()." This parallels the previous sentence and is, I believe, more correct. Within a function, locals() is not the current local namespace, and the following shows that the difference can make a visible difference: >>> def g1(): return op.setitem(locals(), 'x', 1), x ... >>> g1() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in g1 NameError: global name 'x' is not defined >>> def h1(): return eval("op.setitem(locals(), 'x', 1), x") ... >>> h1() (None, 1) After "The return value is the result of the evaluated expression. " add something like It does not depend on the lexical position of the eval call and hence the expression should not contain names that require lexical scoping reaching outside the eval call to be valid." Note that eval scope blocking, the OP's pseudobug, does not require a lambda within the eval-ed expression: >>> def f(x): return lambda: x ... >>> f(1)() 1 >>> def g(x): return lambda: eval('x') ... >>> g(1)() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in File "", line 0, in ? NameError: name 'x' is not defined This might be another example for the PEP. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-03 16:29 Message: Logged In: YES user_id=80475 Jeremy, would you update the pep and docs to cover the OP's examples. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-03 12:16 Message: Logged In: YES user_id=432579 >No, this issue is not specific to either eval or lambda: Right, so let me rephrase: The bug occurs when explicitly evaluating a lambda expression or function definition statement using eval or exec. (This is an artifact of Python's strong separation of statements and expressions.) If this is done "by design", why cannot I find anything anywhere describing this? If this is just a documentation oversight, please say so, but then I would also like to have an explanation of the behaviour. The fact remains that def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why? Both are evaluated at the same time and use the same environment to look up their variables. The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping, because that is how lambda expressions work. >If you want Python to work >differently, write a PEP or a patch, or raise the question in >the newsgroup/mailing list. www.python.org told me that this is the place to report bugs in Python. If that is wrong, we should change the web site. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-02 23:59 Message: Logged In: YES user_id=593130 No, this issue is not specific to either eval or lambda: >>> def f(g): ... exec 'def h(x): return g(x)' ... return h ... >>> f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in h NameError: global name 'g' is not defined It is specific to creating a function at top-level in a separate execution environment, as done, by design, by both eval and exec, and with either a def statement or lambda abbreviation thereof. In Python, lexical scoping works because nested functions are compiled along with the outer function, so that scoped variables can be identified and both functions adjusted so that the coupling works. In particular, the scoped variable has to not be deleted when the outer function returns. Eval/exec compile their string only later, when the function is called. "it works that way because it is the way it works". Those are your words, not mine. If you want Python to work differently, write a PEP or a patch, or raise the question in the newsgroup/mailing list. I'm done discussing it here. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-02 17:42 Message: Logged In: YES user_id=432579 No, this issue is specific to eval of lambda expressions. Please read my problem description. Please refer to the Python documentation if you are confused with how standard function declaration or lexical scoping works. ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 01:20 Message: Logged In: YES user_id=1230541 Obviously I forgot a statement in my previous comment's code example. So here's the complete version: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again n=3 f(2) # the implementation will return 6, but how about your expected implementation? ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 01:15 Message: Logged In: YES user_id=1230541 I think this issue is not special for eval and can be also reproduced with a def statement. The point is that at function definition time Python does not do any variable binding concerning variables not local to the function. Instead Python looks for that variable in the namespace of the module in which the function was created at the time the function is executed. Python determines that module by evaluating the variable __module__ at function definition time and remembers it by setting the function attribute with the same name. That's why only the variable __module__ is relevant at function definition time. Simply put, Python does only do a module level variable binding at function definition time. This is simple and sensible. If you don't agree consider this: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again f(2) # the implementation will return 6, but how about your expected implementation? As you see, changing the implementation would either make Pythons semantics more complicated or would remove much of Pythons dynanism. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 19:26 Message: Logged In: YES user_id=432579 What you are saying is "it works that way because it is the way it works". I see no reason at all for this odd behaviour other than bug-compatibility. I find nothing at all in the documentation supporting this behaviour either; please inform me if I have missed something. All other languages supporting eval and lexical scoping (Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I have no problems if Python wants to be different for whatever reason, but it should be documented. I did a quick Google in comp.lang.python but could not find anything that supported this "exception" or gave a rational explanation. Kindly direct me to any resource you know of that could help enlighten me on this issue. ># From your comments, I suspect you expect 0. Of course not. I know very well how lexical scoping works, so please don't put words in my mouth. None of your examples have anything to do with scoping. As we both know, it is not the _values_ of the variables that is important for variable binding, it is their identity; which variable is chosen, not what they happen to contain at the time the lambda expression is evaluated. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 18:29 Message: Logged In: YES user_id=593130 Whoops. eval('x') == x as code snippets has an exception, which is the one tripping you up. When the eval is within a function definition (and lambda expressions are abbreviated simple function definitions) and 'x' contains a function definition, then the body of the contained function definition does not have access, when it is run, to the locals of the containing function (the lexical scope), whereas it will when x is compiled directly *as part of the containing function body*. eval('x') removes x from that part of its context. eval only has the simple two-level globals/locals environment, which can be anything the caller passes in, so it compiles x as if it were top-level code. Hence free variables in contained functions are looked up in the global passed to eval when the evaled function is called. This issue has been discussed on the Python newsgroup/mailing list more than once. If my explanation is not clear, you might be able to find others in Google c.l.p archives. Do consider that core functions which have been debugged for over a decade are unlike to have many bugs left, although the docs are still being improved. While Python's scoping is lexical, its free variable binding is late. Consider >>> def f(): ... x = 0 ... def g(): print x ... x = 1 ... return g ... >>> f()() # What gets printed? 0 or 1? # From your comments, I suspect you expect 0. # Irregardless, it is 1 Similarly >>> f()() 1 >>> d={'x': 0} >>> h=eval('lambda: x', d, d) >>> h() 0 >>> d['x'] = 1 >>> h() # now what gets printed? 1 ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 10:11 Message: Logged In: YES user_id=432579 >Variables in Python functions are resolved >when the function is *called*, not when it is defined. I'm not sure what you mean by that, since Python obeys lexical scoping, not dynamic.Consider: def f(x): lambda y: x + y When the inner lambda expression above is evaluated, x inside the lambda body is bound to the parameter of the call of f, even if x+y is not evaluated until that function is called. So since def f(x): return eval('x') fetches its definition of x from the lexical variable x, why shouldn't def f(g): return eval('lambda x: g(x)') fetch its definition of g from the lexical variable g? A lambda expression is just a way of delaying evaluation, *not* delaying how variables are bound --- this is done immediately. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 06:30 Message: Logged In: YES user_id=593130 I am 99.5% sure that this is 'invalid' (a Resolution category) and should be closed. With the default environment, eval('x') is the same as unquoted x. Variables in Python functions are resolved when the function is *called*, not when it is defined. There is no resolution for g in the default globals. Eval does not change this. The NameError is exactly correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 From noreply at sourceforge.net Mon Apr 3 19:36:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 10:36:31 -0700 Subject: [ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly Message-ID: Bugs item #1153622, was opened at 2005-02-28 17:48 Message generated for change (Comment added) made by yorick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 6 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Jeremy Hylton (jhylton) Summary: eval does not bind variables in lambda bodies correctly Initial Comment: eval() does not bind variables in lambda expressions correctly: >>>def f(g): return eval('lambda x: g(x)') >>>f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in NameError: global name 'g' is not defined The docs say this about eval(): # If both dictionaries are omitted, the expression is # executed in the environment where eval is called. and using plain local variables work as expected: >>>def h(d): return eval('d(10)') >>>h(lambda y: y * 2) 20 Also, if locals() is presented as the global dict to eval(), it works: >>>def f(g): return eval('lambda x: g(x)', locals(), locals()) >>>f(lambda y: y * 2)(17) 34 but this does not allow the expression to reference global variables of course. ---------------------------------------------------------------------- >Comment By: Mattias Engdeg?rd (yorick) Date: 2006-04-03 19:36 Message: Logged In: YES user_id=432579 Lest my last comment be interpreted as overly arrogant, please be assured that it was not meant as anything other than an explanation of why I reported this as a bug in the first place. I do understand that Python works the way it does; I just want it to be even better. :-) ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2006-04-03 19:12 Message: Logged In: YES user_id=432579 >The source of the problem is that scoping decisions are made >statically. No, because other languages with lexical scope and permitting evaluation at runtime have no problem whatsoever with this. They just answer the question: Q: In what environment is the eval() argument evaluated? typically in one of three ways: A1. In an empty environment with no bindings at all, or just the language-defined standard bindings. A2. In the (or a) top-level environment; local, lexically bound variables where the eval() takes place are not visible to the argument expression. A3. In the same lexical environment as the eval() call itself. Perl and Ruby both say A3. Scheme (R5RS) lets the user specify A1 or A2. Common Lisp answers A2. Observe that none of the answers depend on what the expression looks like. Now, let's be crystal clear about this: The rules of where x is looked up in the expressions 1) x and 2) lambda: x should reasonably be the same - after all, this is fundamentally how lexical scoping works. And Python does indeed work this way, to everybody's satisfaction. In case 2), the evaluation of x is delayed, but that is irrelevant; the decision of what x means is taken at the same time in both cases, and the decision will be the same. Most people would expect Python to answer question Q above with one of the answers A1-3, but it does not, and it does not document what the answer is. The Python answer is rather: A4. A mixed hybrid environment of some kind: The identifiers representing variables that are to be evaluated immediately are looked up in the lexical environment of the eval expression; identifiers representing variables in delayed-evaluation positions use the global environment. This answer is not very satisfactory and I'm inclined to consider a design bug; it is different from what everyone else does and not very intuitive. However, I can accept that it is hard to change now for compatibility reasons. But this answer A4 should be documented. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 17:44 Message: Logged In: YES user_id=31392 The source of the problem is that scoping decisions are made statically. If a variable is determined to be local at compile time, it can't be access as a free variable in dynamically compiled code. The compiler has already determined that the variable is *not* free in the containing function. If a variable is free in a nested function, the compiler treats it differently than if it is merely local to the function. In the most recent cases considered, def f(x): eval('x') -- works because x is a local variable in f. def f(g): eval('lambda x: g(x)') -- does not work because the compiler has determined that g is not used a free variable in f. It isn't possible to change that static analysis at runtime using eval or exec. I agree that the documentation could be clearer here. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 04:46 Message: Logged In: YES user_id=593130 " def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why?" For the same reason def f(g,s): return eval(s) f(lambda x: x, 'lambda x: g(x)')(1) and def g(x): return lambda: eval('x') do not 'work'. eval is a builtin C function whose behavior depends on its arguments (including the somewhat magical defaulting to globals(), local()) and not on its lexical position. " Both are evaluated at the same time and use the same environment to look up their variables." No, the lambda in your second example introduces a new local namespace that is different from the one passed in. " The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping" The delay and change of scoping are correlated. Evaluation is delayed because g is inside a lambda function def which introduces a new local scope which does not contain g, even though the original one did. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-04 03:55 Message: Logged In: YES user_id=593130 After more carefully reading the eval doc in Lib Ref 2.1, I agree that it needs improvement. My suggestions (assuming that my experiment-based inferences are correct): In "The expression argument is parsed and evaluated as a Python expression (technically speaking, a condition list) using the globals and locals dictionaries as global and local name space." insert "in a new top-level environment" before 'using'. This says right-off, even if indirectly, that lexical scoping does not work across the eval call. In "If the locals dictionary is omitted it defaults to the globals dictionary." insert "only" after "If'. If both are omitted, it does not so default. Add a comma after 'omitted', as in the next sentence. In "If both dictionaries are omitted, the expression is executed in the environment where eval is called." replace "the expression ... is called", which I believe to be incorrect as well as misleading, with something like "they default to current globals() and locals()." This parallels the previous sentence and is, I believe, more correct. Within a function, locals() is not the current local namespace, and the following shows that the difference can make a visible difference: >>> def g1(): return op.setitem(locals(), 'x', 1), x ... >>> g1() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in g1 NameError: global name 'x' is not defined >>> def h1(): return eval("op.setitem(locals(), 'x', 1), x") ... >>> h1() (None, 1) After "The return value is the result of the evaluated expression. " add something like It does not depend on the lexical position of the eval call and hence the expression should not contain names that require lexical scoping reaching outside the eval call to be valid." Note that eval scope blocking, the OP's pseudobug, does not require a lambda within the eval-ed expression: >>> def f(x): return lambda: x ... >>> f(1)() 1 >>> def g(x): return lambda: eval('x') ... >>> g(1)() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in File "", line 0, in ? NameError: name 'x' is not defined This might be another example for the PEP. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-03 16:29 Message: Logged In: YES user_id=80475 Jeremy, would you update the pep and docs to cover the OP's examples. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-03 12:16 Message: Logged In: YES user_id=432579 >No, this issue is not specific to either eval or lambda: Right, so let me rephrase: The bug occurs when explicitly evaluating a lambda expression or function definition statement using eval or exec. (This is an artifact of Python's strong separation of statements and expressions.) If this is done "by design", why cannot I find anything anywhere describing this? If this is just a documentation oversight, please say so, but then I would also like to have an explanation of the behaviour. The fact remains that def f(x): eval('x') works as expected and def f(g): eval('lambda x: g(x)') does not. Why? Both are evaluated at the same time and use the same environment to look up their variables. The fact that the 'g' variable in the second case is not evaluated immediately does not affect its scoping, because that is how lambda expressions work. >If you want Python to work >differently, write a PEP or a patch, or raise the question in >the newsgroup/mailing list. www.python.org told me that this is the place to report bugs in Python. If that is wrong, we should change the web site. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-02 23:59 Message: Logged In: YES user_id=593130 No, this issue is not specific to either eval or lambda: >>> def f(g): ... exec 'def h(x): return g(x)' ... return h ... >>> f(lambda y: y * 2)(17) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in h NameError: global name 'g' is not defined It is specific to creating a function at top-level in a separate execution environment, as done, by design, by both eval and exec, and with either a def statement or lambda abbreviation thereof. In Python, lexical scoping works because nested functions are compiled along with the outer function, so that scoped variables can be identified and both functions adjusted so that the coupling works. In particular, the scoped variable has to not be deleted when the outer function returns. Eval/exec compile their string only later, when the function is called. "it works that way because it is the way it works". Those are your words, not mine. If you want Python to work differently, write a PEP or a patch, or raise the question in the newsgroup/mailing list. I'm done discussing it here. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-02 17:42 Message: Logged In: YES user_id=432579 No, this issue is specific to eval of lambda expressions. Please read my problem description. Please refer to the Python documentation if you are confused with how standard function declaration or lexical scoping works. ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 01:20 Message: Logged In: YES user_id=1230541 Obviously I forgot a statement in my previous comment's code example. So here's the complete version: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again n=3 f(2) # the implementation will return 6, but how about your expected implementation? ---------------------------------------------------------------------- Comment By: Branko (bbange) Date: 2005-03-02 01:15 Message: Logged In: YES user_id=1230541 I think this issue is not special for eval and can be also reproduced with a def statement. The point is that at function definition time Python does not do any variable binding concerning variables not local to the function. Instead Python looks for that variable in the namespace of the module in which the function was created at the time the function is executed. Python determines that module by evaluating the variable __module__ at function definition time and remembers it by setting the function attribute with the same name. That's why only the variable __module__ is relevant at function definition time. Simply put, Python does only do a module level variable binding at function definition time. This is simple and sensible. If you don't agree consider this: n=2 def f(x): return n*x del n f(2) # the Python implementation will result in a name error here. But what should happen if Python had bound variable n at the time of f's definitionf? # let's define n again f(2) # the implementation will return 6, but how about your expected implementation? As you see, changing the implementation would either make Pythons semantics more complicated or would remove much of Pythons dynanism. ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 19:26 Message: Logged In: YES user_id=432579 What you are saying is "it works that way because it is the way it works". I see no reason at all for this odd behaviour other than bug-compatibility. I find nothing at all in the documentation supporting this behaviour either; please inform me if I have missed something. All other languages supporting eval and lexical scoping (Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I have no problems if Python wants to be different for whatever reason, but it should be documented. I did a quick Google in comp.lang.python but could not find anything that supported this "exception" or gave a rational explanation. Kindly direct me to any resource you know of that could help enlighten me on this issue. ># From your comments, I suspect you expect 0. Of course not. I know very well how lexical scoping works, so please don't put words in my mouth. None of your examples have anything to do with scoping. As we both know, it is not the _values_ of the variables that is important for variable binding, it is their identity; which variable is chosen, not what they happen to contain at the time the lambda expression is evaluated. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 18:29 Message: Logged In: YES user_id=593130 Whoops. eval('x') == x as code snippets has an exception, which is the one tripping you up. When the eval is within a function definition (and lambda expressions are abbreviated simple function definitions) and 'x' contains a function definition, then the body of the contained function definition does not have access, when it is run, to the locals of the containing function (the lexical scope), whereas it will when x is compiled directly *as part of the containing function body*. eval('x') removes x from that part of its context. eval only has the simple two-level globals/locals environment, which can be anything the caller passes in, so it compiles x as if it were top-level code. Hence free variables in contained functions are looked up in the global passed to eval when the evaled function is called. This issue has been discussed on the Python newsgroup/mailing list more than once. If my explanation is not clear, you might be able to find others in Google c.l.p archives. Do consider that core functions which have been debugged for over a decade are unlike to have many bugs left, although the docs are still being improved. While Python's scoping is lexical, its free variable binding is late. Consider >>> def f(): ... x = 0 ... def g(): print x ... x = 1 ... return g ... >>> f()() # What gets printed? 0 or 1? # From your comments, I suspect you expect 0. # Irregardless, it is 1 Similarly >>> f()() 1 >>> d={'x': 0} >>> h=eval('lambda: x', d, d) >>> h() 0 >>> d['x'] = 1 >>> h() # now what gets printed? 1 ---------------------------------------------------------------------- Comment By: Mattias Engdeg?rd (yorick) Date: 2005-03-01 10:11 Message: Logged In: YES user_id=432579 >Variables in Python functions are resolved >when the function is *called*, not when it is defined. I'm not sure what you mean by that, since Python obeys lexical scoping, not dynamic.Consider: def f(x): lambda y: x + y When the inner lambda expression above is evaluated, x inside the lambda body is bound to the parameter of the call of f, even if x+y is not evaluated until that function is called. So since def f(x): return eval('x') fetches its definition of x from the lexical variable x, why shouldn't def f(g): return eval('lambda x: g(x)') fetch its definition of g from the lexical variable g? A lambda expression is just a way of delaying evaluation, *not* delaying how variables are bound --- this is done immediately. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-01 06:30 Message: Logged In: YES user_id=593130 I am 99.5% sure that this is 'invalid' (a Resolution category) and should be closed. With the default environment, eval('x') is the same as unquoted x. Variables in Python functions are resolved when the function is *called*, not when it is defined. There is no resolution for g in the default globals. Eval does not change this. The NameError is exactly correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470 From noreply at sourceforge.net Mon Apr 3 20:32:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 11:32:58 -0700 Subject: [ python-Bugs-1461115 ] test_winsound fails in 2.4.3 Message-ID: Bugs item #1461115, was opened at 2006-03-30 00:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 Please note that this 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: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. L??wis (loewis) Summary: test_winsound fails in 2.4.3 Initial Comment: The released 2.4.3 Windows installer doesn't include source file Lib/test/check_soundcard.vbs, which causes test_winsound to report 7 bogus failures when run on a box with a sound card. I expect the 2.5 installer also needs to be fiddled to include this file. I confirmed that the problem went away after copying check_soundcard.vbs from a 2.4 branch checkout into the 2.4.3 installation tree. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-03 14:32 Message: Logged In: YES user_id=31435 Thanks, Martin! I wasn't exactly sure what to do, but saw your checkin and see that you did what I guessed should be done -- next time I can do it myself ;-) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 08:18 Message: Logged In: YES user_id=21627 Thanks for the report; this was fixed in 43584 and 43585. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 From noreply at sourceforge.net Mon Apr 3 21:12:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 12:12:52 -0700 Subject: [ python-Bugs-1463559 ] missing svnversion == configure error Message-ID: Bugs item #1463559, was opened at 2006-04-03 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: missing svnversion == configure error Initial Comment: Attempting to build the trunk from source on a box without svn installed spits this out of configure: checking for svnversion... no ./configure: line 3616: test: =: unary operator expected We should handle this more gracefully. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 21:12 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in 43604. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463559&group_id=5470 From noreply at sourceforge.net Mon Apr 3 21:29:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 12:29:56 -0700 Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames Message-ID: Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 Please note that this 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.4 >Status: Open Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) >Assigned to: Georg Brandl (birkenfeld) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-03 21:29 Message: Logged In: YES user_id=11105 The patched file does not even compile. I suggest a more careful review, or running the testsuite (on affected system), or even better, a unittest. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-03 14:26 Message: Logged In: YES user_id=849994 Rev. 43586. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 14:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. ---------------------------------------------------------------------- Comment By: roee88 (roee88) Date: 2006-03-22 13:00 Message: Logged In: YES user_id=1111143 Sorry, but I can't work on a patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 From noreply at sourceforge.net Mon Apr 3 22:06:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 13:06:07 -0700 Subject: [ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed Message-ID: Bugs item #1462485, was opened at 2006-04-01 00:17 Message generated for change (Settings changed) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 Please note that this 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: 7 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Phillip J. Eby (pje) Summary: StopIteration raised in body of 'with' statement suppressed Initial Comment: Given: @contextmanager def gen(): print '__enter__' try: yield finally: print '__exit__' with gen(): raise StopIteration('body') running the above results in: __enter__ __exit__ I would have expected instead __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise StopIteration('body') StopIteration: body Note that doing: with gen(): raise GeneratorExit('body') does the expected thing: __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-04-03 20:06 Message: Logged In: YES user_id=56214 This looks good, although the second GeneratorExit test looks redundant. I went ahead and checked it in, however, on the theory that more tests are better than fewer. :) ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2006-04-02 02:42 Message: Logged In: YES user_id=603121 Attached diffs to test_with.py which adds tests for raising StopIteration (and GeneratorExit) from the body of a with-statement where the context manager is either a generator, or a class instance. I think the correct behaviour is to return False from GeneratorContextManager.__exit__ if the thrown exception is a StopIteration, and the exact same instance is raised from self.gen.throw(). Diffs for this also attached. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:02 Message: Logged In: YES user_id=849994 Nick, I can't tell whether this is intentional without rereading the specs. Can you? ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2006-04-01 00:19 Message: Logged In: YES user_id=603121 Attached code and results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 From noreply at sourceforge.net Mon Apr 3 22:18:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 13:18:27 -0700 Subject: [ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9 Message-ID: Bugs item #1460514, was opened at 2006-03-29 10:28 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Thomas Heller (theller) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-03 22:18 Message: Logged In: YES user_id=11105 As a temporary fix, I removed the '+live_support' attribute in the source file. Andrew, can you please verify that this works for you? Thanks, Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 From noreply at sourceforge.net Mon Apr 3 22:24:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 13:24:10 -0700 Subject: [ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed Message-ID: Bugs item #1462485, was opened at 2006-04-01 00:17 Message generated for change (Comment added) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 Please note that this 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: 7 Submitted By: Tim Delaney (tcdelaney) Assigned to: Phillip J. Eby (pje) Summary: StopIteration raised in body of 'with' statement suppressed Initial Comment: Given: @contextmanager def gen(): print '__enter__' try: yield finally: print '__exit__' with gen(): raise StopIteration('body') running the above results in: __enter__ __exit__ I would have expected instead __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise StopIteration('body') StopIteration: body Note that doing: with gen(): raise GeneratorExit('body') does the expected thing: __enter__ __exit__ Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body ---------------------------------------------------------------------- >Comment By: Tim Delaney (tcdelaney) Date: 2006-04-03 20:24 Message: Logged In: YES user_id=603121 Realised I had a couple of typos in the comment added to contextlib. Fixed diff attached. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2006-04-03 20:06 Message: Logged In: YES user_id=56214 This looks good, although the second GeneratorExit test looks redundant. I went ahead and checked it in, however, on the theory that more tests are better than fewer. :) ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2006-04-02 02:42 Message: Logged In: YES user_id=603121 Attached diffs to test_with.py which adds tests for raising StopIteration (and GeneratorExit) from the body of a with-statement where the context manager is either a generator, or a class instance. I think the correct behaviour is to return False from GeneratorContextManager.__exit__ if the thrown exception is a StopIteration, and the exact same instance is raised from self.gen.throw(). Diffs for this also attached. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:02 Message: Logged In: YES user_id=849994 Nick, I can't tell whether this is intentional without rereading the specs. Can you? ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2006-04-01 00:19 Message: Logged In: YES user_id=603121 Attached code and results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470 From noreply at sourceforge.net Mon Apr 3 23:37:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 14:37:50 -0700 Subject: [ python-Bugs-1463840 ] logging.StreamHandler ignores argument if it compares False Message-ID: Bugs item #1463840, was opened at 2006-04-03 17: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=1463840&group_id=5470 Please note that this 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 Submitted By: Paul Winkler (slinkp) Assigned to: Nobody/Anonymous (nobody) Summary: logging.StreamHandler ignores argument if it compares False Initial Comment: The docs at http://docs.python.org/lib/node346.html say this: """ class StreamHandler( [strm]) Returns a new instance of the StreamHandler class. If strm is specified, the instance will use it for logging output; otherwise, sys.stderr will be used. """ However, that's not quite true. StreamHandler.__init__() actually tests for truth of strm, which means you have to be careful that strm does not happen to evaluate to boolean false. My use case: I'm writing some tests that verify that certain methods put certain strings into the logs. So my setUp() adds a StreamHandler with its stream set to an instance of this trivial class: class FakeLog(list): def write(self, msg): self.append(msg) def flush(self): pass ... which does not work, because an empty list evaluates to false, so my handler writes to stderr even though i told it not to. It's trivial to work around this by adding a __nonzero__ method, but the need to do so is certainly not clear from the docs. Therefore imho this is a bug. The patch is trivial, and is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 From noreply at sourceforge.net Tue Apr 4 01:04:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 16:04:30 -0700 Subject: [ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames Message-ID: Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 Please note that this 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.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) Assigned to: Georg Brandl (birkenfeld) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-04 01:04 Message: Logged In: YES user_id=21627 For the record: the patch *does* compile (though with warnings), and passes the test suite, see the buildbot log files for details. Nevertheless, there were two serious bugs in the code, which I fixed in 43611. Thanks for pointing that out. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-03 21:29 Message: Logged In: YES user_id=11105 The patched file does not even compile. I suggest a more careful review, or running the testsuite (on affected system), or even better, a unittest. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-03 14:26 Message: Logged In: YES user_id=849994 Rev. 43586. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-03 14:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. ---------------------------------------------------------------------- Comment By: roee88 (roee88) Date: 2006-03-22 13:00 Message: Logged In: YES user_id=1111143 Sorry, but I can't work on a patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 From noreply at sourceforge.net Tue Apr 4 02:54:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 17:54:45 -0700 Subject: [ python-Bugs-1463926 ] can't build on cygwin - PyArg_Parse_SizeT undefined Message-ID: Bugs item #1463926, was opened at 2006-04-04 10:54 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=1463926&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: can't build on cygwin - PyArg_Parse_SizeT undefined Initial Comment: Something's not right on cygwin with the trunk. Example failing build: http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-configure/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-compile/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-test/0 Wrapping the PY_SSIZE_T_CLEAN bit at the top of modsupport.h in an "#if 0"/"#endif" makes it compile, at least. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 From noreply at sourceforge.net Tue Apr 4 08:20:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 23:20:17 -0700 Subject: [ python-Bugs-1463840 ] logging.StreamHandler ignores argument if it compares False Message-ID: Bugs item #1463840, was opened at 2006-04-03 14:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 Please note that this 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 Submitted By: Paul Winkler (slinkp) >Assigned to: Vinay Sajip (vsajip) Summary: logging.StreamHandler ignores argument if it compares False Initial Comment: The docs at http://docs.python.org/lib/node346.html say this: """ class StreamHandler( [strm]) Returns a new instance of the StreamHandler class. If strm is specified, the instance will use it for logging output; otherwise, sys.stderr will be used. """ However, that's not quite true. StreamHandler.__init__() actually tests for truth of strm, which means you have to be careful that strm does not happen to evaluate to boolean false. My use case: I'm writing some tests that verify that certain methods put certain strings into the logs. So my setUp() adds a StreamHandler with its stream set to an instance of this trivial class: class FakeLog(list): def write(self, msg): self.append(msg) def flush(self): pass ... which does not work, because an empty list evaluates to false, so my handler writes to stderr even though i told it not to. It's trivial to work around this by adding a __nonzero__ method, but the need to do so is certainly not clear from the docs. Therefore imho this is a bug. The patch is trivial, and is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 23:20 Message: Logged In: YES user_id=33168 Vinay, any comments? We are preparing for 2.5 alpha1 within a day. There will be freeze real soon now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 From noreply at sourceforge.net Tue Apr 4 08:27:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Apr 2006 23:27:41 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 07:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) >Assigned to: Martin v. L??wis (loewis) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 23:27 Message: Logged In: YES user_id=33168 Martin maintains PyXML AFAIK. Maybe he has some ideas. I suspect this might be even worse in 2.5. Element Tree was added and there was a name change. Some of those things still need to be addressed. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-03 06:37 Message: Logged In: YES user_id=200117 Hi Neal, I've just built 2.4.3 on a Red Hat Enterpeise Edition WS V4.2 machine and this gives the same error. I've had this vague feeling that I've seen something like this before, but couldn't find anything when I searched the tracker... I've now realised that the error is due to a conflict with PyXML-0.8.4 which was already installed on both machines. If I rename the ../site_packages/_xmlplus directory to a different name then the error goes away (on the Red Hat machine at least, the SUSE machine is at home). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-02 22:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 07:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Tue Apr 4 10:47:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 01:47:30 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 14: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=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Tue Apr 4 21:42:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 12:42:46 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21: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=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Tue Apr 4 22:43:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 13:43:58 -0700 Subject: [ python-Bugs-1463926 ] can't build on cygwin - PyArg_Parse_SizeT undefined Message-ID: Bugs item #1463926, was opened at 2006-04-03 17:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: can't build on cygwin - PyArg_Parse_SizeT undefined Initial Comment: Something's not right on cygwin with the trunk. Example failing build: http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-configure/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-compile/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-test/0 Wrapping the PY_SSIZE_T_CLEAN bit at the top of modsupport.h in an "#if 0"/"#endif" makes it compile, at least. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 13:43 Message: Logged In: YES user_id=33168 Anthony fixed this. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 From noreply at sourceforge.net Tue Apr 4 23:14:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 14:14:11 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 23: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=1464506&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Wed Apr 5 00:14:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 15:14:58 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Wed Apr 5 00:16:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 15:16:09 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Wed Apr 5 00:43:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 15:43:48 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Wed Apr 5 01:44:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 16:44:14 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-04 19: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=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Wed Apr 5 01:53:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 16:53:14 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-04 19:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-04-04 19:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Wed Apr 5 05:38:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 20:38:24 -0700 Subject: [ python-Bugs-1464658 ] PyList_GetItem() clarification Message-ID: Bugs item #1464658, was opened at 2006-04-04 23:38 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=1464658&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: PyList_GetItem() clarification Initial Comment: The PyList_GetItem function is documented at http://docs.python.org/api/listObjects.html as returning "...the object at position pos...". However, even though in python -1 is a valid index, this function expects a 'real' index. 1) I believe it would be worthwhile pointing out in the API docs that in fact a positive value is expected. 2) It would be good to change the function signature to expect an unsigned int instead of an int for the index. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 From noreply at sourceforge.net Wed Apr 5 06:38:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Apr 2006 21:38:11 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 14:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 21:38 Message: Logged In: YES user_id=33168 Heh, I added ldd support in ctypes/_loader.py _findLib_ld. Does that address this issue? Or perhaps at least partially address? It looks like in the current buildbot, this part of ctypes isn't failing. Maybe this can be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Wed Apr 5 10:27:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 01:27:19 -0700 Subject: [ python-Bugs-1460493 ] Why not drop the _active list? Message-ID: Bugs item #1460493, was opened at 2006-03-29 07:16 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-05 08:27 Message: Logged In: YES user_id=1276121 the implementation in 2.5 of popen2 seems good if you or astrand could patch subprocess.py accordingly, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-30 16:31 Message: Logged In: YES user_id=21627 attila-cheops, please read the 2.5 version of popen2. popen2 now only adds processes to _active in __del__, not in __init__, so the problem with the application still wanting to wait/poll is solved. Multiple threads simultaneously isn't a problem, since it is (or should be) harmless to invoke poll on a process that has already been waited for. For only one of the poll calls, the wait will actually succeed, and that should be the one that removes it from the _active list. The same strategy should be applied to subprocess. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:17 Message: Logged In: YES user_id=1276121 also #1214859 is interesting, has a patch ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:06 Message: Logged In: YES user_id=1276121 the same problem probably exists in popen2.py there _active is also used so if something is fixed in subprocess.py, it should probably also be fixed in popen2.py ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:04 Message: Logged In: YES user_id=1276121 what happens if you are doing a _cleanup (iterating over a copy of _active) in multiple threads? can it not happen then that you clean up a process 2 times? thread 1 starts a _cleanup: makes a copy of _active[:] and starts polling thread 2 starts a _cleanup: makes a copy of _active[:] and starts polling thread 1 encounters a finished process and removes it from _active[] thread 2 does not know the process is removed, finds the same process finished and tries to remove it from _active but this fails, because thread 1 removed it already so the action of cleaning up should maybe be serialized if 1 thread is doing it, the other one should block everyone who needs this can of course patch the subprocess.py file, but shouldn't this be fixed in the library? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-30 07:43 Message: Logged In: YES user_id=33168 If you always called wait() the _active list isn't beneficial to you. However, many people do not call wait and the _active list provides a mechanism to cleanup zombied children. This is important for many users. If you need thread safely, you can handle the locking yourself before calling poll()/wait(). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-29 20:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 From noreply at sourceforge.net Wed Apr 5 11:02:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 02:02:48 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 23:14 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-05 11:02 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-05 06:38 Message: Logged In: YES user_id=33168 Heh, I added ldd support in ctypes/_loader.py _findLib_ld. Does that address this issue? Or perhaps at least partially address? It looks like in the current buildbot, this part of ctypes isn't failing. Maybe this can be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Wed Apr 5 13:59:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 04:59:22 -0700 Subject: [ python-Bugs-1464658 ] PyList_GetItem() clarification Message-ID: Bugs item #1464658, was opened at 2006-04-05 03:38 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: PyList_GetItem() clarification Initial Comment: The PyList_GetItem function is documented at http://docs.python.org/api/listObjects.html as returning "...the object at position pos...". However, even though in python -1 is a valid index, this function expects a 'real' index. 1) I believe it would be worthwhile pointing out in the API docs that in fact a positive value is expected. 2) It would be good to change the function signature to expect an unsigned int instead of an int for the index. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-05 11:59 Message: Logged In: YES user_id=1126061 I agree with these suggestions. It's not impossible for someone to 'just assume' a negative index is handled correctly by PyList_GetItem(). +1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 From noreply at sourceforge.net Wed Apr 5 14:57:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 05:57:46 -0700 Subject: [ python-Bugs-1462440 ] udp multicast setsockopt fails Message-ID: Bugs item #1462440, was opened at 2006-03-31 15:16 Message generated for change (Comment added) made by abgrover You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462440&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: udp multicast setsockopt fails Initial Comment: Using setsockopt to join a multicast group for a udp socket fails on windows (works on linux). Test reproduction: run the attached file expected behavior: The snd thread sends three udp packets to the multicast address. The rcv thread reads three udp packets. observed behavior on linux: the expected behavior observed behavior on windows: Exception in thread rcv: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "C:\Python24\lib\threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "E:\svn\TTC\trunk\agrover\src\SmcTestCase\multicastbug.py", line 12, in rcv s.setsockopt(SOL_IP, IP_ADD_MEMBERSHIP, sopt) File "", line 1, in setsockopt error: (10022, 'Invalid argument') ---------------------------------------------------------------------- >Comment By: Alan G (abgrover) Date: 2006-04-05 06:57 Message: Logged In: YES user_id=1098341 More details of config: Windows used is XP Pro SP2 Linuxen used include Fedora Core and Mandrake ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462440&group_id=5470 From noreply at sourceforge.net Wed Apr 5 16:19:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 07:19:38 -0700 Subject: [ python-Bugs-1464978 ] test_urllib2 and test_mimetypes = failure Message-ID: Bugs item #1464978, was opened at 2006-04-06 00: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=1464978&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_urllib2 and test_mimetypes = failure Initial Comment: Logging here because I don't have time to look into it at the moment. On Linux at least, "regrtest test_urllib2 test_mimetypes" will fail, because the mimetypes module's global dictionaries get modified by urllib2. The proper fix is to probably edit test_mimetypes to remove the assumptions that it knows what's in the mimetypes dictionary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464978&group_id=5470 From noreply at sourceforge.net Wed Apr 5 16:06:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 07:06:31 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 23:14 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-05 16:06 Message: Logged In: YES user_id=11105 Actually the bug in in the ctypes test module. nnorwitz's change helps loading libraries, but not to determine which libraries should by loaded. doko's method allows to fix this. I'll commit a patch soon, thanks. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 11:02 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-05 06:38 Message: Logged In: YES user_id=33168 Heh, I added ldd support in ctypes/_loader.py _findLib_ld. Does that address this issue? Or perhaps at least partially address? It looks like in the current buildbot, this part of ctypes isn't failing. Maybe this can be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Wed Apr 5 17:14:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 08:14:13 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-05 11: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=1465014&group_id=5470 Please note that this 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: 7 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Wed Apr 5 17:35:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 08:35:26 -0700 Subject: [ python-Bugs-967934 ] csv module cannot handle embedded \r Message-ID: Bugs item #967934, was opened at 2004-06-07 00:46 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967934&group_id=5470 Please note that this 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 Submitted By: Gregory Bond (gnbond) Assigned to: Andrew McNamara (andrewmcnamara) Summary: csv module cannot handle embedded \r Initial Comment: CSV module cannot handle the case of embedded \r (i.e. carriage return) in a field. As far as I can see, this is hard-coded into the _csv.c file and cannot be fixed with Dialect changes. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2006-04-05 11:35 Message: Logged In: YES user_id=7733 I just filed a bug (http://www.python.org/sf/1465014) that seems to be related to this. Revision 38290 on Modules/_csv.c includes the addition of this code: else if (c == '\n' || c == '\r') { self->state = EAT_CRNL; break; } (and similar). This seems to be eating (deleting) control chars, but newlines used to be significant. Embedded line breaks are allowed, according to RFC 4180 (http://www.ietf.org/rfc/rfc4180.txt). And according to the Wikipedia entry (http://en.wikipedia.org/wiki/Comma-separated_values), "a line break within an element must be preserved." ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2005-01-13 06:34 Message: Logged In: YES user_id=698599 If you're interested, I've just checked in a change to the CVS head for Python 2.5 that may, at least partially, fix this problem (if you try it, let me know how it goes). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-06-07 07:25 Message: Logged In: YES user_id=44345 It certainly intersects with it somehow. ;-) If nothing else, it will serve as a useful test case. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2004-06-07 01:32 Message: Logged In: YES user_id=698599 I suspect this restriction (CR appearing within a quoted field) is a historical accident and can be safely removed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-07 01:02 Message: Logged In: YES user_id=80475 Skip, does this coincide with your planned switchover to universal newlines? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967934&group_id=5470 From noreply at sourceforge.net Wed Apr 5 17:44:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 08:44:12 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: Bugs item #1465014, was opened at 2006-04-05 11:14 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this 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: 7 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2006-04-05 11:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Wed Apr 5 17:56:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 08:56:33 -0700 Subject: [ python-Bugs-1465093 ] Error with 2.5a1 MSI installer Message-ID: Bugs item #1465093, was opened at 2006-04-05 16:56 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=1465093&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Error with 2.5a1 MSI installer Initial Comment: Installing 2.5a1 on Windows XP Pro SP2. I changed the install directory to D:\Apps\Python25, and selected "compile all modules" from the advanced options screen. Everything else is as standard. The install stopped with a message "There is a problem with ths Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." This was right after the compile of all modules. There's plenty of free disk space on the machine. Rerunning without the "compile all modules" selection worked fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 From noreply at sourceforge.net Wed Apr 5 17:57:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 08:57:18 -0700 Subject: [ python-Bugs-1465093 ] Error with 2.5a1 MSI installer Message-ID: Bugs item #1465093, was opened at 2006-04-05 16:56 Message generated for change (Settings changed) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Martin v. L??wis (loewis) Summary: Error with 2.5a1 MSI installer Initial Comment: Installing 2.5a1 on Windows XP Pro SP2. I changed the install directory to D:\Apps\Python25, and selected "compile all modules" from the advanced options screen. Everything else is as standard. The install stopped with a message "There is a problem with ths Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." This was right after the compile of all modules. There's plenty of free disk space on the machine. Rerunning without the "compile all modules" selection worked fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 From noreply at sourceforge.net Wed Apr 5 19:15:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 10:15:18 -0700 Subject: [ python-Bugs-1465093 ] Error with 2.5a1 MSI installer Message-ID: Bugs item #1465093, was opened at 2006-04-05 16:56 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: Error with 2.5a1 MSI installer Initial Comment: Installing 2.5a1 on Windows XP Pro SP2. I changed the install directory to D:\Apps\Python25, and selected "compile all modules" from the advanced options screen. Everything else is as standard. The install stopped with a message "There is a problem with ths Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." This was right after the compile of all modules. There's plenty of free disk space on the machine. Rerunning without the "compile all modules" selection worked fine. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-04-05 18:15 Message: Logged In: YES user_id=113328 Another data point - the pywin32 binary installer for 2.5 also fails, with an error saying that the preinstall script couldn't run. In both cases, it's an installer trying to run a Python script. I did a *very* quick test, and running scripts from the command line does work OK... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 From noreply at sourceforge.net Wed Apr 5 20:40:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 11:40:39 -0700 Subject: [ python-Bugs-1463104 ] problems with os.system and shell redirection on Windows XP Message-ID: Bugs item #1463104, was opened at 2006-04-02 13:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463104&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: problems with os.system and shell redirection on Windows XP Initial Comment: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 - Windows XP SP2 N.B. sorry for italian error messages. With the following script: # redirection.py import os import sys os.system(sys.argv[1]) ---------------- When doing: redirection.py "dir" > redirection.txt I obtain: Spazio su disco insufficiente. Instead with: redirection.py "svn help" > redirection.txt svn: Errore di scrittura: Bad file descriptor This is a Python problem because with an equivalent program written in C++: // redirection.c++ #include int main(int argc, char** argv) { std::system(argv[1]); } --------------------------------- there are no problems. Thanks and regards Manlio Perillo ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-05 14:40 Message: Logged In: YES user_id=31435 Sorry, there's nothing Python can do about this -- it's a well-known family of Windows bugs, and affects all scripts (regardless of language) that try to combine command line I/O redirection with implicit determination of the executable via file association. As you've discovered, it doesn't effect .exe files (which is why your C++ example isn't relevant). Various versions of Windows fail in various ways, but in no version of Windows to date have all the redirections bugs been fixed. For example, here I'll reproduce your symptoms exactly with Perl scripts on WinXP, although the error messages are English: C:\Perl\bin>type blah1.pl system("dir"); C:\Perl\bin>blah1.pl > out.txt There is not enough space on the disk. C:\Perl\bin>type blah2.pl system("svn help"); C:\Perl\bin>blah2.pl > out.txt svn: Write error: Bad file descriptor The simplest and most reliable workaround is to put the path to the executable first on the command line. Here are the same Perl examples doing that; the same kind of thing works for all cases in which Windows redirection doesn't work (including, of course, Python): C:\Perl\bin>.\perl blah1.pl > out.txt C:\Perl\bin>type out.txt Volume in drive C has no label. Volume Serial Number is 5C0F-48E6 Directory of C:\Perl\bin 04/05/2006 02:29 PM . 04/05/2006 02:29 PM .. 02/04/2003 03:35 PM 90,175 a2p.exe [etc] C:\Perl\bin>.\perl blah2.pl > out.txt C:\Perl\bin>type out.txt usage: svn [options] [args] Subversion command-line client, version 1.2.3. [etc] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463104&group_id=5470 From noreply at sourceforge.net Wed Apr 5 22:21:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 13:21:22 -0700 Subject: [ python-Bugs-1463104 ] problems with os.system and shell redirection on Windows XP Message-ID: Bugs item #1463104, was opened at 2006-04-02 17:18 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463104&group_id=5470 Please note that this 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: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: problems with os.system and shell redirection on Windows XP Initial Comment: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 - Windows XP SP2 N.B. sorry for italian error messages. With the following script: # redirection.py import os import sys os.system(sys.argv[1]) ---------------- When doing: redirection.py "dir" > redirection.txt I obtain: Spazio su disco insufficiente. Instead with: redirection.py "svn help" > redirection.txt svn: Errore di scrittura: Bad file descriptor This is a Python problem because with an equivalent program written in C++: // redirection.c++ #include int main(int argc, char** argv) { std::system(argv[1]); } --------------------------------- there are no problems. Thanks and regards Manlio Perillo ---------------------------------------------------------------------- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-04-05 20:21 Message: Logged In: YES user_id=1054957 Thanks for the detailed response. As a joke, I have written this code at the begin of the script: os.dup2(2, 3) # backup fd 2 os.dup2(1, 2) os.dup2(2, 1) os.dup2(3, 2) # restore fd 2 and it *seems* to work! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-05 18:40 Message: Logged In: YES user_id=31435 Sorry, there's nothing Python can do about this -- it's a well-known family of Windows bugs, and affects all scripts (regardless of language) that try to combine command line I/O redirection with implicit determination of the executable via file association. As you've discovered, it doesn't effect .exe files (which is why your C++ example isn't relevant). Various versions of Windows fail in various ways, but in no version of Windows to date have all the redirections bugs been fixed. For example, here I'll reproduce your symptoms exactly with Perl scripts on WinXP, although the error messages are English: C:\Perl\bin>type blah1.pl system("dir"); C:\Perl\bin>blah1.pl > out.txt There is not enough space on the disk. C:\Perl\bin>type blah2.pl system("svn help"); C:\Perl\bin>blah2.pl > out.txt svn: Write error: Bad file descriptor The simplest and most reliable workaround is to put the path to the executable first on the command line. Here are the same Perl examples doing that; the same kind of thing works for all cases in which Windows redirection doesn't work (including, of course, Python): C:\Perl\bin>.\perl blah1.pl > out.txt C:\Perl\bin>type out.txt Volume in drive C has no label. Volume Serial Number is 5C0F-48E6 Directory of C:\Perl\bin 04/05/2006 02:29 PM . 04/05/2006 02:29 PM .. 02/04/2003 03:35 PM 90,175 a2p.exe [etc] C:\Perl\bin>.\perl blah2.pl > out.txt C:\Perl\bin>type out.txt usage: svn [options] [args] Subversion command-line client, version 1.2.3. [etc] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463104&group_id=5470 From noreply at sourceforge.net Thu Apr 6 00:46:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 15:46:37 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 23:14 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-06 00:46 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-05 16:06 Message: Logged In: YES user_id=11105 Actually the bug in in the ctypes test module. nnorwitz's change helps loading libraries, but not to determine which libraries should by loaded. doko's method allows to fix this. I'll commit a patch soon, thanks. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 11:02 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-05 06:38 Message: Logged In: YES user_id=33168 Heh, I added ldd support in ctypes/_loader.py _findLib_ld. Does that address this issue? Or perhaps at least partially address? It looks like in the current buildbot, this part of ctypes isn't failing. Maybe this can be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Thu Apr 6 01:11:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 16:11:37 -0700 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 16:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-05 19:11 Message: Logged In: YES user_id=6380 What's this waiting for? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-22 15:56 Message: Logged In: YES user_id=89016 I think this patch can go in. Any objections from Raymond or Fred against this? ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-16 20:04 Message: Logged In: YES user_id=1375527 Walter, I agree that there still seems to be an issue with _format() calling _repr() multiple times, however this patch seems to enable my feature request using sub- classing. Can the other issue (which exists presently also) be ignored for now? Could you submit the patch, or is that something I should do? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 13:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 13:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 12:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 06:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 04:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 15:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 14:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 12:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 17:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 16:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Thu Apr 6 01:30:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 16:30:06 -0700 Subject: [ python-Feature Requests-1465406 ] Allowing the definition of constants Message-ID: Feature Requests item #1465406, was opened at 2006-04-05 23:30 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=1465406&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 From noreply at sourceforge.net Thu Apr 6 01:34:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 16:34:12 -0700 Subject: [ python-Bugs-1465408 ] HP-UX11i installation failure Message-ID: Bugs item #1465408, was opened at 2006-04-05 16:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 From noreply at sourceforge.net Thu Apr 6 01:57:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 16:57:49 -0700 Subject: [ python-Feature Requests-1465406 ] Allowing the definition of constants Message-ID: Feature Requests item #1465406, was opened at 2006-04-05 18:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-05 18:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 From noreply at sourceforge.net Thu Apr 6 02:31:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 17:31:35 -0700 Subject: [ python-Bugs-1390321 ] Building without C++ should not fail. Message-ID: Bugs item #1390321, was opened at 2005-12-25 23:11 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) >Assigned to: Martin v. L??wis (loewis) >Summary: Building without C++ should not fail. Initial Comment: This just verified against HEAD: ./configure fails on Linux without g++ installed unless --without-cxx given. README should mention this. Error is checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables Inside config.log it says: gcc: installation problem, cannot exec 'cc1plus': No such file or directory (There's been some discussion about not requiring C++ installation by default -- until that's settled, we should at least update the README.) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-05 20:31 Message: Logged In: YES user_id=3066 The group notes this is for Python 2.5, but I think it applies to 2.4.x as well. Re-categorizing as a build issue since Martin says it is. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-12-27 19:03 Message: Logged In: YES user_id=21627 The real solution to this problem is that configure shouldn't fail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390321&group_id=5470 From noreply at sourceforge.net Thu Apr 6 02:45:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 17:45:50 -0700 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-03-31 19:23 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Nick Coghlan (ncoghlan) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-05 20:45 Message: Logged In: YES user_id=6380 I'm not so sure. Who looks at the top of the traceback anyway? And it might hide clues about problems caused by runpy.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Thu Apr 6 07:38:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 22:38:41 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 14:17 Message generated for change (Comment added) made by vnainar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: nomind (vnainar) Date: 2006-04-06 11:08 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 03:46 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Thu Apr 6 08:44:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Apr 2006 23:44:56 -0700 Subject: [ python-Bugs-1451341 ] msgfmt.py: fuzzy messages not correctly found Message-ID: Bugs item #1451341, was opened at 2006-03-16 15:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hanno Schlichting (hannosch) Assigned to: Nobody/Anonymous (nobody) Summary: msgfmt.py: fuzzy messages not correctly found Initial Comment: In the msgfmt.py script which is installed in %PYTHON_HOME%\Tools\i18n (on Windows) on line 129 to 131 it says: # Record a fuzzy mark if l[:2] == '#,' and l.find('fuzzy'): fuzzy = 1 this should be: # Record a fuzzy mark if l[:2] == '#,' and l.find('fuzzy') > -1: fuzzy = 1 or all lines beginning with '#,' will be treated as fuzzy. Only change is the "> -1". This applies to all versions of Python. It has been brought to my attention by Andrey Lebedev who found this in a product which uses a slightly modified msgfmt.py. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 06:44 Message: Logged In: YES user_id=849994 Fixed in rev. 43684, 43685. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 15:16 Message: Logged In: YES user_id=1126061 Yup, the bug is in trunk. Although I suggest # Record a fuzzy mark if l[:2] == '#,' and 'fuzzy' in l: as it's more readable (and I got shouted at by Tim the other day for using s.find() when 'in' would have done). Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470 From noreply at sourceforge.net Thu Apr 6 09:38:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 00:38:29 -0700 Subject: [ python-Bugs-1464978 ] test_urllib2 and test_mimetypes = failure Message-ID: Bugs item #1464978, was opened at 2006-04-06 00:19 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464978&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: test_urllib2 and test_mimetypes = failure Initial Comment: Logging here because I don't have time to look into it at the moment. On Linux at least, "regrtest test_urllib2 test_mimetypes" will fail, because the mimetypes module's global dictionaries get modified by urllib2. The proper fix is to probably edit test_mimetypes to remove the assumptions that it knows what's in the mimetypes dictionary. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:38 Message: Logged In: YES user_id=29957 Fixed in 43688 (trunk) and 43689 (release24-maint) I moved the default setting into a new function, and made test_mimetypes call that to reset things to a known state. module level global dictionaries suck. :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464978&group_id=5470 From noreply at sourceforge.net Thu Apr 6 09:46:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 00:46:58 -0700 Subject: [ python-Bugs-1465554 ] Cygwin installer should create a link to libpython2.5.dll.a Message-ID: Bugs item #1465554, was opened at 2006-04-06 10:46 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=1465554&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin installer should create a link to libpython2.5.dll.a Initial Comment: Installer should create a link to /usr/lib/python25/config/libpython2.5.dll.a in /usr/lib /usr/lib/python25/config is *not* in the linker path and build extensions using distutils don't work. Create a link in /usr/lib fixes the problem. Another option is to change distutils to add /usr/lib/python25/config to linker path on cygwin platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465554&group_id=5470 From noreply at sourceforge.net Thu Apr 6 09:48:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 00:48:21 -0700 Subject: [ python-Bugs-1465408 ] HP-UX11i installation failure Message-ID: Bugs item #1465408, was opened at 2006-04-06 09:34 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 From noreply at sourceforge.net Thu Apr 6 09:56:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 00:56:22 -0700 Subject: [ python-Bugs-1465408 ] HP-UX11i installation failure Message-ID: Bugs item #1465408, was opened at 2006-04-06 09:34 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 From noreply at sourceforge.net Thu Apr 6 09:58:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 00:58:10 -0700 Subject: [ python-Bugs-1465408 ] HP-UX11i installation failure Message-ID: Bugs item #1465408, was opened at 2006-04-06 09:34 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 Please note that this 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 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 From noreply at sourceforge.net Thu Apr 6 10:15:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 01:15:05 -0700 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: Matt Fleming (splitscreen) Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 08:15 Message: Logged In: YES user_id=849994 splitscreen: your patch was incomplete and could have overwritten memory. tim_one: Attaching new patch implementing what I proposed in my comment below. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 21:59 Message: Logged In: YES user_id=1126061 Ok, uploading latest patch, not quite sure I've hit the mark here. Please review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 20:43 Message: Logged In: YES user_id=849994 Yes, I want to remove 'U' from the mode since it's at this point already recognized by Python, and it's not meaningful to the underlying C library. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 19:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Thu Apr 6 11:33:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 02:33:23 -0700 Subject: [ python-Bugs-1465600 ] zipfile - arcname must be encode in cp437 Message-ID: Bugs item #1465600, was opened at 2006-04-06 11:33 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=1465600&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile - arcname must be encode in cp437 Initial Comment: In the doc should be a note insert: The arcnames in zipfile must be encoded in cp437 I think it should be insert here: http://docs.python.org/lib/zipfile-objects.html Look the comments in this bug: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=878120 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465600&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:03:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:03:47 -0700 Subject: [ python-Bugs-1465600 ] zipfile - arcname must be encode in cp437 Message-ID: Bugs item #1465600, was opened at 2006-04-06 09:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465600&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile - arcname must be encode in cp437 Initial Comment: In the doc should be a note insert: The arcnames in zipfile must be encoded in cp437 I think it should be insert here: http://docs.python.org/lib/zipfile-objects.html Look the comments in this bug: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=878120 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 10:03 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 43699, 43700. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465600&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:05:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:05:48 -0700 Subject: [ python-Bugs-1465619 ] str.decode('rot13') produces Unicode Message-ID: Bugs item #1465619, was opened at 2006-04-06 10: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=1465619&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: str.decode('rot13') produces Unicode Initial Comment: In 3.8.3 Standard Encodings, the table at the bottom listing special encodings says that the result of str.decode('rot13') is a byte string. In Python 2.4.3 it is actually a Unicode string so this table entry should be changed. In [40]: 'abc'.decode('rot13') Out[40]: u'nop' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:39:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:39:31 -0700 Subject: [ python-Bugs-878120 ] Zipfile archive name can't be unicode Message-ID: Bugs item #878120, was opened at 2004-01-16 10:32 Message generated for change (Comment added) made by pylucid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&group_id=5470 Please note that this 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.3 Status: Deleted Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile archive name can't be unicode Initial Comment: In Python 2.3.2, The following code: import zipfile z = zipfile.ZipFile( "file.zip", "w" ) z.write( "file.txt", u"file.txt" ) z.close() Results in this exception: Traceback (most recent call last): File "E:\dev\ziptest.py", line 8, in ? z.write( "file.txt", u"file.txt" ) File "D:\Python23\lib\zipfile.py", line 412, in write self.fp.write(zinfo.FileHeader()) File "D:\Python23\lib\zipfile.py", line 166, in FileHeader return header + self.filename + self.extra UnicodeDecodeError: 'ascii' codec can't decode byte 0xd5 in position 10: ordinal not in range(128) The code could be fixed in zipfile.py. Something along the lines of: return header + self.filename.encode("utf-8") + self.extra On Windows ideally the code should figure out the current locale's codepage and use that to encode the filename into the correct multibyte sequence. The example above is pretty easy to spot, but if the arcname is coming from a COM property (my case) it takes a while to figure out why zipfile is crashing! This is bug 705295 resubmitted: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=705295&group_id=5470 ---------------------------------------------------------------------- Comment By: Jens Diemer (pylucid) Date: 2006-04-06 12:39 Message: Logged In: YES user_id=1330780 Hm! Which occurs to me straight: Shouldn't Python make the conversion automaticly? If the arcname is type unicode, Python should convert it to cp437. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-01-18 15:54 Message: Logged In: YES user_id=21627 I don't know who the info-zip walker is, but atleast Winzip will interpret all file names as CP437. This becomes obvious when you try to unzip a file name with non-ASCII characters on Windows NT: the resulting Unicode file names are generated as-if the encoding used is code page 437. I believe this is the same in pkware. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-01-18 12:42 Message: Logged In: YES user_id=775521 I would be happy to just see an exception indicating that the supplied filename mustn't be unicode, to save people time figuring this one out in the future. I can supply a patch but I thought this was too trivial for that. You wrote: >Names in zip files are stored in code page 437 Correct me if I'm wrong, but won't the info-zip directory walker just stick whatever it enumerates into the name field? I don't quite understand what you mean by 'no support'. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-01-18 00:56 Message: Logged In: YES user_id=21627 Using UTF-8 is incorrect. Names in zip files are stored in code page 437. There is no support for file names outside this character set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:44:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:44:48 -0700 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 (Tracker Item Submitted) made by Item Submitter 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 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465643&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:53:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:53:48 -0700 Subject: [ python-Bugs-878120 ] Zipfile archive name can't be unicode Message-ID: Bugs item #878120, was opened at 2004-01-16 09:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&group_id=5470 Please note that this 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.3 Status: Deleted Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile archive name can't be unicode Initial Comment: In Python 2.3.2, The following code: import zipfile z = zipfile.ZipFile( "file.zip", "w" ) z.write( "file.txt", u"file.txt" ) z.close() Results in this exception: Traceback (most recent call last): File "E:\dev\ziptest.py", line 8, in ? z.write( "file.txt", u"file.txt" ) File "D:\Python23\lib\zipfile.py", line 412, in write self.fp.write(zinfo.FileHeader()) File "D:\Python23\lib\zipfile.py", line 166, in FileHeader return header + self.filename + self.extra UnicodeDecodeError: 'ascii' codec can't decode byte 0xd5 in position 10: ordinal not in range(128) The code could be fixed in zipfile.py. Something along the lines of: return header + self.filename.encode("utf-8") + self.extra On Windows ideally the code should figure out the current locale's codepage and use that to encode the filename into the correct multibyte sequence. The example above is pretty easy to spot, but if the arcname is coming from a COM property (my case) it takes a while to figure out why zipfile is crashing! This is bug 705295 resubmitted: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=705295&group_id=5470 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 10:53 Message: Logged In: YES user_id=849994 There's no specs that say which encoding the file names should have. That WinZip uses cp437 is its own choice. Other sources tell "Zip programs by default assume the filenames are encoded using the code page of the machine", so it's better to leave the encoding to the user of zipfile. ---------------------------------------------------------------------- Comment By: Jens Diemer (pylucid) Date: 2006-04-06 10:39 Message: Logged In: YES user_id=1330780 Hm! Which occurs to me straight: Shouldn't Python make the conversion automaticly? If the arcname is type unicode, Python should convert it to cp437. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-01-18 14:54 Message: Logged In: YES user_id=21627 I don't know who the info-zip walker is, but atleast Winzip will interpret all file names as CP437. This becomes obvious when you try to unzip a file name with non-ASCII characters on Windows NT: the resulting Unicode file names are generated as-if the encoding used is code page 437. I believe this is the same in pkware. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-01-18 11:42 Message: Logged In: YES user_id=775521 I would be happy to just see an exception indicating that the supplied filename mustn't be unicode, to save people time figuring this one out in the future. I can supply a patch but I thought this was too trivial for that. You wrote: >Names in zip files are stored in code page 437 Correct me if I'm wrong, but won't the info-zip directory walker just stick whatever it enumerates into the name field? I don't quite understand what you mean by 'no support'. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-01-17 23:56 Message: Logged In: YES user_id=21627 Using UTF-8 is incorrect. Names in zip files are stored in code page 437. There is no support for file names outside this character set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878120&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:57:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:57:57 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 11:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Thu Apr 6 12:59:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 03:59:31 -0700 Subject: [ python-Bugs-1465619 ] str.decode('rot13') produces Unicode Message-ID: Bugs item #1465619, was opened at 2006-04-06 10:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Walter D?rwald (doerwalter) Summary: str.decode('rot13') produces Unicode Initial Comment: In 3.8.3 Standard Encodings, the table at the bottom listing special encodings says that the result of str.decode('rot13') is a byte string. In Python 2.4.3 it is actually a Unicode string so this table entry should be changed. In [40]: 'abc'.decode('rot13') Out[40]: u'nop' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 10:59 Message: Logged In: YES user_id=849994 Walter: Wouldn't make it sense for rot13 to actually output byte strings? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 From noreply at sourceforge.net Thu Apr 6 13:18:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 04:18:32 -0700 Subject: [ python-Bugs-1465619 ] str.decode('rot13') produces Unicode Message-ID: Bugs item #1465619, was opened at 2006-04-06 12:05 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Walter D?rwald (doerwalter) Summary: str.decode('rot13') produces Unicode Initial Comment: In 3.8.3 Standard Encodings, the table at the bottom listing special encodings says that the result of str.decode('rot13') is a byte string. In Python 2.4.3 it is actually a Unicode string so this table entry should be changed. In [40]: 'abc'.decode('rot13') Out[40]: u'nop' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-04-06 13:18 Message: Logged In: YES user_id=38388 rot 13 returns Unicode because it uses the charmap codec which works this way. I don't see much of a reason to change this. The documentation will have to be updated, though. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 12:59 Message: Logged In: YES user_id=849994 Walter: Wouldn't make it sense for rot13 to actually output byte strings? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 From noreply at sourceforge.net Thu Apr 6 13:25:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 04:25:57 -0700 Subject: [ python-Bugs-1465619 ] str.decode('rot13') produces Unicode Message-ID: Bugs item #1465619, was opened at 2006-04-06 10:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Walter D?rwald (doerwalter) Summary: str.decode('rot13') produces Unicode Initial Comment: In 3.8.3 Standard Encodings, the table at the bottom listing special encodings says that the result of str.decode('rot13') is a byte string. In Python 2.4.3 it is actually a Unicode string so this table entry should be changed. In [40]: 'abc'.decode('rot13') Out[40]: u'nop' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 11:25 Message: Logged In: YES user_id=849994 Okay. Fixed docs in rev. 43701, 43702. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-04-06 11:18 Message: Logged In: YES user_id=38388 rot 13 returns Unicode because it uses the charmap codec which works this way. I don't see much of a reason to change this. The documentation will have to be updated, though. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 10:59 Message: Logged In: YES user_id=849994 Walter: Wouldn't make it sense for rot13 to actually output byte strings? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465619&group_id=5470 From noreply at sourceforge.net Thu Apr 6 14:25:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 05:25:58 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 23:14 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 Please note that this 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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-06 14:25 Message: Logged In: YES user_id=11105 This is fixed now. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 00:46 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-05 16:06 Message: Logged In: YES user_id=11105 Actually the bug in in the ctypes test module. nnorwitz's change helps loading libraries, but not to determine which libraries should by loaded. doko's method allows to fix this. I'll commit a patch soon, thanks. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 11:02 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-05 06:38 Message: Logged In: YES user_id=33168 Heh, I added ldd support in ctypes/_loader.py _findLib_ld. Does that address this issue? Or perhaps at least partially address? It looks like in the current buildbot, this part of ctypes isn't failing. Maybe this can be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Thu Apr 6 14:31:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 05:31:28 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 15:03 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Martin v. L??wis (loewis) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 13:31 Message: Logged In: YES user_id=200117 Interestingly, the error doesn't occur with Python-2.5a1 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 07:27 Message: Logged In: YES user_id=33168 Martin maintains PyXML AFAIK. Maybe he has some ideas. I suspect this might be even worse in 2.5. Element Tree was added and there was a name change. Some of those things still need to be addressed. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-03 14:37 Message: Logged In: YES user_id=200117 Hi Neal, I've just built 2.4.3 on a Red Hat Enterpeise Edition WS V4.2 machine and this gives the same error. I've had this vague feeling that I've seen something like this before, but couldn't find anything when I searched the tracker... I've now realised that the error is due to a conflict with PyXML-0.8.4 which was already installed on both machines. If I rename the ../site_packages/_xmlplus directory to a different name then the error goes away (on the Red Hat machine at least, the SUSE machine is at home). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 06:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 15:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Thu Apr 6 14:34:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 05:34:02 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Thu Apr 6 14:46:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 05:46:16 -0700 Subject: [ python-Bugs-1464658 ] PyList_GetItem() clarification Message-ID: Bugs item #1464658, was opened at 2006-04-05 03:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: PyList_GetItem() clarification Initial Comment: The PyList_GetItem function is documented at http://docs.python.org/api/listObjects.html as returning "...the object at position pos...". However, even though in python -1 is a valid index, this function expects a 'real' index. 1) I believe it would be worthwhile pointing out in the API docs that in fact a positive value is expected. 2) It would be good to change the function signature to expect an unsigned int instead of an int for the index. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 12:46 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 43704, 43705. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-05 11:59 Message: Logged In: YES user_id=1126061 I agree with these suggestions. It's not impossible for someone to 'just assume' a negative index is handled correctly by PyList_GetItem(). +1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 From noreply at sourceforge.net Thu Apr 6 14:47:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 05:47:07 -0700 Subject: [ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname Message-ID: Bugs item #1464506, was opened at 2006-04-04 23:14 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes testsuite hardcodes libc soname Initial Comment: on Debian alpha-linux and Debian/Ubuntu hppa-linux, libc's soname is libc.so.6.1. A more portable way to find about the libc soname might be to check ldd on the python executable (or any other executable) $ ldd /bin/ls | awk '/libc\.so/ {print $3}' /lib/tls/libc.so.6.1 $ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}' libc.so.6.1 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-06 14:47 Message: Logged In: YES user_id=11105 Resolution is 'fixed', not 'duplicate'. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:25 Message: Logged In: YES user_id=11105 This is fixed now. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 00:46 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-05 16:06 Message: Logged In: YES user_id=11105 Actually the bug in in the ctypes test module. nnorwitz's change helps loading libraries, but not to determine which libraries should by loaded. doko's method allows to fix this. I'll commit a patch soon, thanks. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 11:02 Message: Logged In: YES user_id=60903 no, please see http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/11/step-test/0 (that's the last run of current trunk, AFAIK) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-05 06:38 Message: Logged In: YES user_id=33168 Heh, I added ldd support in ctypes/_loader.py _findLib_ld. Does that address this issue? Or perhaps at least partially address? It looks like in the current buildbot, this part of ctypes isn't failing. Maybe this can be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470 From noreply at sourceforge.net Thu Apr 6 14:51:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 05:51:18 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-04 23:44 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) >Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-04 23:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Thu Apr 6 15:01:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 06:01:10 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 10:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 13:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Thu Apr 6 15:02:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 06:02:46 -0700 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-04-06 15:02 Message: Logged In: YES user_id=89016 Can this still be checked in after 2.5a1 is out the door? It is a new feature not just a bug fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-06 01:11 Message: Logged In: YES user_id=6380 What's this waiting for? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-22 21:56 Message: Logged In: YES user_id=89016 I think this patch can go in. Any objections from Raymond or Fred against this? ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-17 02:04 Message: Logged In: YES user_id=1375527 Walter, I agree that there still seems to be an issue with _format() calling _repr() multiple times, however this patch seems to enable my feature request using sub- classing. Can the other issue (which exists presently also) be ignored for now? Could you submit the patch, or is that something I should do? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 19:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 19:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 18:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 12:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 10:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 21:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 20:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Thu Apr 6 15:12:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 06:12:43 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Thu Apr 6 16:42:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 07:42:30 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 11:57 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 15:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 14:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Thu Apr 6 16:45:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 07:45:51 -0700 Subject: [ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError Message-ID: Bugs item #1446043, was opened at 2006-03-08 19:55 Message generated for change (Comment added) made by osvenskan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: osvenskan (osvenskan) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode('foo', '.utf99') does not raise LookupError Initial Comment: A very minor inconsistency -- when I call unicode() with an encoding that Python doesn't know about, it usually returns a lookup error (e.g LookupError: unknown encoding: utf99). But when the encoding begins with a dot (ASCII 0x2e), Python instead gives a ValueError: Empty module name. It is certainly correct in raising an error, but it should raise a lookup error, not a value error. I've recreated this under Python 2.4.1/FreeBSD 6.0 and 2.3/OS X. See attachment for recreation steps. ---------------------------------------------------------------------- >Comment By: osvenskan (osvenskan) Date: 2006-04-06 10:45 Message: Logged In: YES user_id=1119995 I noticed that the documentation for unicode() says, "if the encoding is not known, LookupError is raised". Regarding the 3rd parameter ("errors") to unicode(), the docs say, "Error handling is done according to errors; this specifies the treatment of characters which are invalid in the input encoding. If errors is 'strict' (the default), a ValueError is raised on errors..." ref: http://docs.python.org/lib/built-in-funcs.html That makes the code's current behavior doubly confusing because a the documentation says that a ValueError is reserved for indicating an undecodable byte sequence, not an unknown encoding name. ---------------------------------------------------------------------- Comment By: osvenskan (osvenskan) Date: 2006-03-09 10:04 Message: Logged In: YES user_id=1119995 There are encoding names that contain dots, such as ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as reported by iconv). There are none in iconv's list that begin with a dot. Please note that the behavior of this function has been discussed before in Python bugs 513666 and 960874. Apologies for not referencing them in my original report. Having stepped through the code, I understand how the ValueError is getting generated. My frustration with this as a programmer is that I want to write specific except clauses for each possible exception that a method can raise, but that's impractical if any exception is fair game on any method. So I'm forced to use a catch-all except clause about which the Python documentation says (wisely, IMHO), "Use this with extreme caution, since it is easy to mask a real programming error in this way!" While it is helpful to document errors that a method is *likely* to raise, my code needs to handle all possibilities, not just likely ones. Perhaps the answer is just, "This is how Python works" and if I feel it is a weakness in the language I need to take it up on a different level. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 03:16 Message: Logged In: YES user_id=849994 Is it possible for an encoding name to contain dots at all? If not, this would do too: if '.' in modname: continue ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-09 03:12 Message: Logged In: YES user_id=89016 The problem is that after normalizing the encoding name a module with this name is imported. Maybe encodings/__init__.py:search_function should do: if ".".join(filter(None, modname.split("."))) != modname: return None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470 From noreply at sourceforge.net Thu Apr 6 17:34:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 08:34:54 -0700 Subject: [ python-Feature Requests-1437699 ] allow unicode arguments for robotparser.can_fetch Message-ID: Feature Requests item #1437699, was opened at 2006-02-23 16:07 Message generated for change (Comment added) made by osvenskan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470 Please note that this 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 Submitted By: osvenskan (osvenskan) Assigned to: Skip Montanaro (montanaro) Summary: allow unicode arguments for robotparser.can_fetch Initial Comment: One-line summary: If the robotparser module encounters a robots.txt file that contains non-ASCII characters AND I pass a Unicode user agent string to can_fetch(), that function crashes with a TypeError under Python 2.4. Under Python 2.3, the error is a UnicodeDecodeError. More detail: When one calls can_fetch(MyUserAgent, url), the robotparser module compares the UserAgent to each user agent described in the robots.txt file. If isinstance(MyUserAgent, str) == True then the comparison does not raise an error regardless of the contents of robots.txt. However, if isinstance(MyUserAgent, unicode) == True, then Python implicitly tries to convert the contents of the robots.txt file to Unicode before comparing it to MyUserAgent. By default, Python assumes a US-ASCII encoding when converting, so if the contents of robots.txt aren't ASCII, the conversion fails. In other words, this works: MyRobotParser.can_fetch('foobot', url) but this fails: MyRobotParser.can_fetch(u'foobot', url) I recreated this with Python 2.4.1 on FreeBSD 6 and Python 2.3 under Darwin/OS X. I'll attach examples from both. The URLs that I use in the attachments are from my Web site and will remain live. They reference robots.txt files which contain an umlaut-ed 'a' (0xe4 in iso-8859-1). They're served up using a special .htaccess file that adds a Content-Type header which correctly identifies the encoding used for each file. Here's the contents of the .htaccess file: AddCharset iso-8859-1 .iso8859-1 AddCharset utf-8 .utf8 A suggested solution: AFAICT, the construction of robots.txt is still defined by "a consensus on 30 June 1994 on the robots mailing list" [http://www.robotstxt.org/wc/norobots.html] and a 1996 draft proposal [http://www.robotstxt.org/wc/norobots-rfc.html] that has never evolved into a formal standard. Neither of these mention character sets or encodings which is no surprise considering that they date back to the days when the Internet was poor but happy and we considered even ASCII a luxury and we were grateful to have it. ("ASCII? We used to dream of having ASCII. We only had one bit, and it was a zero. We lived in a shoebox in the middle of the road..." etc.) A backwards-compatible yet forward-looking solution would be to have the robotparser module respect the Content-Type header sent with robots.txt. If no such header is present, robotparser should try to decode it using iso-8859-1 per section 3.7.1 of the HTTP 1.1 spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1) which says, 'When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value.' Section 3.6.1 of the HTTP 1.0 spec says the same. Since ISO-8859-1 is a superset of US-ASCII, robots.txt files that are pure ASCII won't be affected by the change. ---------------------------------------------------------------------- >Comment By: osvenskan (osvenskan) Date: 2006-04-06 11:34 Message: Logged In: YES user_id=1119995 I've also discovered that robotparser can get confused by files with BOMs (byte order marks). At minimum it should ignore BOMs, at best it should use them as clues as to the file's encoding. It does neither, and instead treats the BOM as character data. That's especially problematic when the robots.txt file consists of this: [BOM]User-agent: * Disallow: / In that case, robotparser fails to recognize the string "User-agent", so the disallow rule is ignored, which in turn means it treats the file as empty and all robots are permitted everywhere which is the exact opposite of what the author intended. If the first line is a comment, then robotparser doesn't get confused regardless of whether or not there's a BOM. I created a sample robots.txt file exactly like the one above; it contains a utf-8 BOM. The example below uses this file which is on my Web site. >>> import robotparser >>> rp=robotparser.RobotFileParser() >>> rp.set_url("http://semanchuk.com/philip/boneyard/robots/robots.txt.bom") >>> rp.read() >>> rp.can_fetch("foobot", "/") # should return False True >>> My robot parser module doesn't suffer from the BOM bug (although it doesn't use BOMs to decode the file, either, which it really ought to). As I said before, You're welcome to steal code from it or copy it wholesale (it is GPL). Also, I'll be happy to open a different bug report if you feel like this should be a separate issue. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-20 14:33 Message: Logged In: YES user_id=38388 Reassigning to Skip: I don't use robotparser. Skip, perhaps you can have a look ? (Didn't you write the robotparser ?) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-18 05:17 Message: Logged In: YES user_id=849994 Turning into a Feature Request. ---------------------------------------------------------------------- Comment By: osvenskan (osvenskan) Date: 2006-03-07 11:32 Message: Logged In: YES user_id=1119995 Thanks for looking at this. I have some followup comments. The list at robotstxt.org is many years stale (note that Google's bot is present only as Backrub which was still a server at Stanford at the time: http://www.robotstxt.org/wc/active/html/backrub.html) but nevertheless AFAICT it is the most current bot list on the Web. If you look carefully, the list *does* contain a non-ASCII entry (#76 --easy to miss in that long list). That Finnish bot is gone but it has left a legacy in the form of many robots.txt files that were created by automated tools based on the robotstxt.org list. Google helps us here: http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3Atxt And by Googling for some common non-ASCII words and letters I can find more like this one (look at the end of the alphabetical list): http://paranormal.se/robots.txt Robots.txt files that contain non-ASCII are few and far between, it seems, but they're out there. Which leads me to a nitpicky (but important!) point about Unicode. As you point out, the spec doesn't mention Unicode; it says nothing at all on the topic of encodings. My argument is that just because the spec doesn't mention encodings doesn't let us off the hook because the HTTP 1.0/1.1 specs are very clear that iso-8859-1, not US-ASCII, is the default for text content delivered via HTTP. By my interpretation, this means that the robots.txt examples provided above are compliant with published specs, therefore code that fails to interpret them does not comply. There's no obvious need for robotparser to support full-blown Unicode, just iso-8859-1. You might be interested in a replacement for this module that I've implemented. It does everything that robotparser does and also handles non-ASCII plus a few other things. It is GPL; you're welcome to copy it in part or lock, stock and barrel. So far I've only tested it "in the lab" but I've done fairly extensive unit testing and I'll soon be testing it on real-world data. The code and docs are here: http://semanchuk.com/philip/boneyard/rerp/ Comments & feedback would be most welcome. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 22:01 Message: Logged In: YES user_id=593130 To me, this is not a bug report but at best an RFE. The reported behavior is what I would expect. I read both module doc and the referenced web page and further links. The doc does not mention Unicode as allowed and the 300 registered UserAgents at http://www.robotstxt.org/wc/active/html/index.html all have ascii names. So I recomment closing this as a bug report but will give ML a chance to respond. If switched instead to Feature Request, I would think it would need some 'in the wild' evidence of need. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1437699&group_id=5470 From noreply at sourceforge.net Thu Apr 6 17:48:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 08:48:08 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 10:57 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 15:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 14:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 13:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Thu Apr 6 18:16:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 09:16:21 -0700 Subject: [ python-Bugs-1465408 ] HP-UX11i installation failure Message-ID: Bugs item #1465408, was opened at 2006-04-05 16:34 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 Please note that this 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 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-06 09:16 Message: Logged In: YES user_id=71407 I get a complete build if I touch Include/Python-ast.h Python/Python-ast.c before running configure. If you wait a second after the svn export and then touch these two files I'd expect the tarball to work out of the box. Another idea is to work with MD5 signatures, like SCons does. But if you don't have a Python yet it is probably difficult to find a fully portable solution. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 00:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 00:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 From noreply at sourceforge.net Thu Apr 6 18:40:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 09:40:20 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 17:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Thu Apr 6 18:53:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 09:53:37 -0700 Subject: [ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags Message-ID: Bugs item #1465838, was opened at 2006-04-06 09:53 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=1465838&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 From noreply at sourceforge.net Thu Apr 6 20:13:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 11:13:04 -0700 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 16:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-06 14:13 Message: Logged In: YES user_id=6380 IMO yes. Assigning to Anthony for pronouncement (it's a pretty small feature as features go). Feature freeze isn't until beta 1 is shipped (although for bigger features we'd like to see them in, in rough form, sooner, of course). Anthony, feel free to assign back to Walter to check it in if you're ok with that. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-06 09:02 Message: Logged In: YES user_id=89016 Can this still be checked in after 2.5a1 is out the door? It is a new feature not just a bug fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-05 19:11 Message: Logged In: YES user_id=6380 What's this waiting for? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-22 15:56 Message: Logged In: YES user_id=89016 I think this patch can go in. Any objections from Raymond or Fred against this? ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-16 20:04 Message: Logged In: YES user_id=1375527 Walter, I agree that there still seems to be an issue with _format() calling _repr() multiple times, however this patch seems to enable my feature request using sub- classing. Can the other issue (which exists presently also) be ignored for now? Could you submit the patch, or is that something I should do? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 13:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 13:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 12:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 06:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 04:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 15:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 14:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 12:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 17:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 16:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Thu Apr 6 20:15:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 11:15:55 -0700 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 16:29 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this 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 Submitted By: Mark Hirota (markhirota) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-06 14:13 Message: Logged In: YES user_id=6380 IMO yes. Assigning to Anthony for pronouncement (it's a pretty small feature as features go). Feature freeze isn't until beta 1 is shipped (although for bigger features we'd like to see them in, in rough form, sooner, of course). Anthony, feel free to assign back to Walter to check it in if you're ok with that. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-06 09:02 Message: Logged In: YES user_id=89016 Can this still be checked in after 2.5a1 is out the door? It is a new feature not just a bug fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-05 19:11 Message: Logged In: YES user_id=6380 What's this waiting for? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-22 15:56 Message: Logged In: YES user_id=89016 I think this patch can go in. Any objections from Raymond or Fred against this? ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-16 20:04 Message: Logged In: YES user_id=1375527 Walter, I agree that there still seems to be an issue with _format() calling _repr() multiple times, however this patch seems to enable my feature request using sub- classing. Can the other issue (which exists presently also) be ignored for now? Could you submit the patch, or is that something I should do? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 13:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 13:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 12:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 06:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 04:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 15:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 14:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 12:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 17:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 16:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Thu Apr 6 20:22:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 11:22:23 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Thu Apr 6 20:34:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 11:34:00 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 12:57 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-04-06 20:34 Message: Logged In: YES user_id=89016 I'm prepared to throw out the fancy tests from test_pwd.py and test_grp.py. They don't buy us much anyway and basically test more the OS then the Python modules. (For related bugs see #779218, #962226 and #775964.) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 16:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 15:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Thu Apr 6 21:17:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 12:17:21 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Thu Apr 6 21:45:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 12:45:39 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Thu Apr 6 22:01:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 13:01:08 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 17:40 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-04-06 21:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 19:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Thu Apr 6 22:02:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 13:02:18 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Thu Apr 6 22:38:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 13:38:47 -0700 Subject: [ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit Message-ID: Bugs item #1061968, was opened at 2004-11-07 09:30 Message generated for change (Comment added) made by midtoad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Please note that this 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.3 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. ---------------------------------------------------------------------- Comment By: Stewart Midwinter (midtoad) Date: 2006-04-06 14:38 Message: Logged In: YES user_id=190543 What's the current status of this bug? Did the bug fix make it into 2.4.3? When I run test13.py (attached to one of the notes for this bug) with Python 2.4.3, it does not crash - does that mean that the bug has been fixed? If not, will it be possible to have the fix included in 2.5? thanks Stewart ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-12-04 04:46 Message: Logged In: YES user_id=4771 Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3. Closing the bug report... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-02 09:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 00:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-01 23:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-08 07:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 21:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 18:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 15:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 15:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 12:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurrent() call by a call to PyGILState_Release(), and the latter-- like Python before rev 2.41 --does *not* hold the GIL when it decides to delete the tstate. That's the source of the timing hole you're falling into here. Offhand I'm not sure what to do about it, because I'm not familiar with the other bug Mark was trying to fix with rev 2.59. I'm assigning to Mark under the hope that it will be instantly obvious to him. Mark, if it's not, please assign it to me, and I'll try to work it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 From noreply at sourceforge.net Thu Apr 6 23:46:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 14:46:18 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Thu Apr 6 23:59:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 14:59:06 -0700 Subject: [ python-Feature Requests-1465406 ] Allowing the definition of constants Message-ID: Feature Requests item #1465406, was opened at 2006-04-05 23:30 Message generated for change (Comment added) made by ciw42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 Please note that this 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: None >Status: Open >Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? ---------------------------------------------------------------------- >Comment By: Chris Wilson (ciw42) Date: 2006-04-06 21:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-05 23:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 From noreply at sourceforge.net Fri Apr 7 01:58:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 16:58:51 -0700 Subject: [ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit Message-ID: Bugs item #1061968, was opened at 2004-11-07 11:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Please note that this 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.3 Status: Closed Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-06 19:58 Message: Logged In: YES user_id=31435 midtoad: This bug was closed in December of 2004. The fix was in 2.4 release candidate 1, also in late 2004. It never existed in 2.5. Move along, folks, nothing to see here ;-) ---------------------------------------------------------------------- Comment By: Stewart Midwinter (midtoad) Date: 2006-04-06 16:38 Message: Logged In: YES user_id=190543 What's the current status of this bug? Did the bug fix make it into 2.4.3? When I run test13.py (attached to one of the notes for this bug) with Python 2.4.3, it does not crash - does that mean that the bug has been fixed? If not, will it be possible to have the fix included in 2.5? thanks Stewart ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-12-04 06:46 Message: Logged In: YES user_id=4771 Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3. Closing the bug report... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-02 11:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 02:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 01:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-08 09:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 23:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 20:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 17:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 17:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 14:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurrent() call by a call to PyGILState_Release(), and the latter-- like Python before rev 2.41 --does *not* hold the GIL when it decides to delete the tstate. That's the source of the timing hole you're falling into here. Offhand I'm not sure what to do about it, because I'm not familiar with the other bug Mark was trying to fix with rev 2.59. I'm assigning to Mark under the hope that it will be instantly obvious to him. Mark, if it's not, please assign it to me, and I'll try to work it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 From noreply at sourceforge.net Fri Apr 7 03:19:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Apr 2006 18:19:53 -0700 Subject: [ python-Bugs-1466065 ] base64 module ignores non-alphabet characters Message-ID: Bugs item #1466065, was opened at 2006-04-07 10: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=1466065&group_id=5470 Please note that this 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 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: base64 module ignores non-alphabet characters Initial Comment: See: http://mail.python.org/pipermail/python-dev/2006-April/063504.html base64.b64decode function ignores non-alphabet characters, which contradicts its documentation: see http://docs.python.org/lib/module-base64.html Also, the exception must be ValueError instead of TypeError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466065&group_id=5470 From noreply at sourceforge.net Fri Apr 7 12:03:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 03:03:00 -0700 Subject: [ python-Bugs-1465093 ] Error with 2.5a1 MSI installer Message-ID: Bugs item #1465093, was opened at 2006-04-05 17:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 Please note that this 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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: Error with 2.5a1 MSI installer Initial Comment: Installing 2.5a1 on Windows XP Pro SP2. I changed the install directory to D:\Apps\Python25, and selected "compile all modules" from the advanced options screen. Everything else is as standard. The install stopped with a message "There is a problem with ths Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor." This was right after the compile of all modules. There's plenty of free disk space on the machine. Rerunning without the "compile all modules" selection worked fine. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-07 12:03 Message: Logged In: YES user_id=21627 Thanks for the report. This is fixed in r43719. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-05 19:15 Message: Logged In: YES user_id=113328 Another data point - the pywin32 binary installer for 2.5 also fails, with an error saying that the preinstall script couldn't run. In both cases, it's an installer trying to run a Python script. I did a *very* quick test, and running scripts from the command line does work OK... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465093&group_id=5470 From noreply at sourceforge.net Fri Apr 7 12:07:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 03:07:03 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 15:03 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Martin v. L??wis (loewis) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-07 11:07 Message: Logged In: YES user_id=200117 I added a few print statements to the tests - see attached file py_243.txt for the results while running on Python- 2.4.3 ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 13:31 Message: Logged In: YES user_id=200117 Interestingly, the error doesn't occur with Python-2.5a1 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 07:27 Message: Logged In: YES user_id=33168 Martin maintains PyXML AFAIK. Maybe he has some ideas. I suspect this might be even worse in 2.5. Element Tree was added and there was a name change. Some of those things still need to be addressed. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-03 14:37 Message: Logged In: YES user_id=200117 Hi Neal, I've just built 2.4.3 on a Red Hat Enterpeise Edition WS V4.2 machine and this gives the same error. I've had this vague feeling that I've seen something like this before, but couldn't find anything when I searched the tracker... I've now realised that the error is due to a conflict with PyXML-0.8.4 which was already installed on both machines. If I rename the ../site_packages/_xmlplus directory to a different name then the error goes away (on the Red Hat machine at least, the SUSE machine is at home). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 06:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 15:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Fri Apr 7 12:13:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 03:13:09 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 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=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-07 12:13 Message: Logged In: YES user_id=21627 We should drop the tests in a selective manner. In this case, if -2 is in the password/group file, we should be able to find it: somebody might want to search by a gid value entered from a user, and that ought to work as well. rptownsend: could you investigate in more detail what's going on, on your system? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-06 20:34 Message: Logged In: YES user_id=89016 I'm prepared to throw out the fancy tests from test_pwd.py and test_grp.py. They don't buy us much anyway and basically test more the OS then the Python modules. (For related bugs see #779218, #962226 and #775964.) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 17:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 16:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 15:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Fri Apr 7 13:12:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 04:12:36 -0700 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-04-01 10:23 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nick Coghlan (ncoghlan) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 21:12 Message: Logged In: YES user_id=1038590 I'd forgotten about SF's current "no email when assigned a bug" feature. . . I'm inclined to agree with Guido that it could be tricky to get rid of these without also masking legitimate traceback info for import errors (e.g. if the PEP 302 emulation machinery blows up rather than returning None the way it is meant to when it can't find a loader for the module). OTOH, I don't like the current output for an import errror, either: C:\>C:\python25\python.exe -m junk Traceback (most recent call last): File "C:\Python25\Lib\runpy.py", line 410, in run_module raise ImportError("No module named " + mod_name) ImportError: No module named junk So I'll look into it - if it is suspected that runpy is at fault for a problem with running a script, then there's two easy ways to get the full traceback: C:\>C:\python25\python.exe -m runpy junk C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-06 10:45 Message: Logged In: YES user_id=6380 I'm not so sure. Who looks at the top of the traceback anyway? And it might hide clues about problems caused by runpy.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Fri Apr 7 13:28:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 04:28:19 -0700 Subject: [ python-Feature Requests-1432694 ] Implement preemptive threads in Python Message-ID: Feature Requests item #1432694, was opened at 2006-02-16 18:11 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470 Please note that this 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: Invalid Priority: 5 Submitted By: Andrey Petrov (darkprokoba) Assigned to: Michael Hudson (mwh) Summary: Implement preemptive threads in Python Initial Comment: Cooperative threads have their uses but I find the lack of real native pre-emptive threads a major issue in a 21-st century language. We should consider the inertia of programmers from C++/Java/.NET background. They are used to and experienced in solving certain kind of problems with pre-emptive threads, and it's just too plain inconvenient to step back and try to cope with cooperative threads. The idea behind Python is that programming should not be a pain, right? This applies especially to GUI programs, where threads are used to perform time-consuming work in order to avoid the GUI from freezing (was I surprised the first time I tried this in Python!) Just look at some of the modern Python GUI applications, found in some recent Linux distributions. 99% of Fedora's configuration tools suffer extreme usability issues caused by their single-threadedness. I hate using yumex because the GUI is basically frozen for the half minute it takes to reload all repos I have configured on my machine!!! I know there might be a way to alleviate this particual class of problems by more careful cooperative thread programing... but I believe we need a more straightforward solution (i.e. preemptive threads) and not workarounds. I apologize if this issue has already been raised before. Cheers, darkprokoba ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 21:28 Message: Logged In: YES user_id=1038590 One addition to Josiah's comments is that the previous attempts at free-threading failed to gain an appreciable performance benefit, as the gains from removing the global lock were lost in the subsequent need to add explicit synchronisation everywhere. Free threading is not a panacea. If Queue.Queue is used to pass data to worker threads, idle threads will not be consuming any GIL time. If there is OS level context-switch thrashing going on, then its time to look at using thread pools instead of a thread per task. Now, if you were to rephrase this request as "I want to be able to make the GUI thread higher priority than the worker threads so I can have a gazillion threads without hurting responsiveness of the main event loop so badly", that would be an entirely different story, and not a question I have seen asked recently (or at all, in fact). (Josiah's comments about any such thing being a couple of years away still hold, however - the multi-process support libraries are here and now, and scale a lot better than threads ever will, no matter what language you use) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-02-22 18:35 Message: Logged In: YES user_id=341410 How many worker threads do you expect? If you work the sys.setcheckinterval() just right, you may be able to prioritize your threads... Any C library which does not acquire and release the GIL when it is supposed to is broken. Claiming that Python is broken in relation to C libraries being broken is misplaced blame. Python uses a GIL because it makes interaction with Python objects easier across threads. There have been previous failed efforts to make Python scalable across multiple processors; search for "python free threading" on google to see all of the relevant information about rewriting the Python interpreter with multiple processors in mind. Alternatively, you can always use one of the half-dozen parallel processing libraries for Python to distribute your work onto different processors, who all synchronize up with the main GUI process. Some are quite intuitive (check out Kamaelia), and will work today (any effort to get a 'free threading' idea into Python core will have to wait until at least Python 2.6, which is at least 2 years away). ---------------------------------------------------------------------- Comment By: Andrey Petrov (darkprokoba) Date: 2006-02-22 17:55 Message: Logged In: YES user_id=950037 > thread context switches happen at a regular > rate thanks for your response, but with enough worker threads it's still easy to starve the GUI thread. and the other problems of this model remain: 1) a stupid native module could forget to release the global interpreter lock and block on I/O, freezing the entire interpreter (i.e. GIL is a pain for native module writers) 2) poor CPU utilization on SMP machines (which are quite mainstream now) Python's model just doesn't cut it for me (I'm well aware now of how it works) so my question boils down to: Do the python authors plan to make the interpreter reentrant and if so when can we expect to see this in a production release? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-02-22 15:44 Message: Logged In: YES user_id=341410 If GUI applications are written properly, they don't need to hang when they are doing "real work". The applications you are using which seem to hang are doing so not because Python "doesn't have preemptive threads", they are doing so because the writers of those GUI applications have no idea how to either 1. write their programs asynchronously via generators or callbacks or 2. use threads to do the actual work which post GUI update events. Talk to the writers of those applications to get them fixed. Note that regardless of Python's lack of preemptive multithreading, thread context switches happen at a regular rate, discoverable via sys.getcheckinterval(), and setable via sys.setcheckinterval(). ---------------------------------------------------------------------- Comment By: Andrey Petrov (darkprokoba) Date: 2006-02-17 19:52 Message: Logged In: YES user_id=950037 OK, let me try again :-) The problem is in the global interpreter lock: http://docs.python.org/api/threads.html this basically says that you can have as many native threads as you like but only one of them could have the global interpreter lock and could therefore be executing python code at a time. The only use of python's multiple threads then is so they could release the global lock and block on i/o operations while one lucky thread has the lock and executes python code and accesses python objects happily. So we have multiple native threads (e.g. pthreads) but they pass arround the global lock in a cooperative manner. This is not preemptive threading imho. It's a severely limited model and has the following potential problem: a thread may enter a time-consuming i/o operation but forget to release the global interpreter lock - leading to a freeze in the entire interpreter (all threads are waiting for the global lock, while the thread that has it waits on the i/o operation) Are there any plans for alleviating this problem? A thread should not voluntarily release the lock so that the rest of the threads get a chance to execute python code. It should be possible to preempt any thread at any time without its consent in order to have a true preemptive threading model. Or please correct me If I'm wrong. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-17 00:14 Message: Logged In: YES user_id=6656 We _have_ preemptive threads in Python ("import threading"). Suggest you report a real problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470 From noreply at sourceforge.net Fri Apr 7 14:41:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 05:41:47 -0700 Subject: [ python-Bugs-1466301 ] ImportError: Module _subprocess not found Message-ID: Bugs item #1466301, was opened at 2006-04-07 14:41 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=1466301&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Africanis (africanis) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: Module _subprocess not found Initial Comment: I'm using Enthought Python 2.3.5 together with IPython and matplotlib on Windows XP SP2. I had problems importing pylab (in order actually to use matplotlib) until I changed the attached file (see from line 365). I have absolutely no idea what effect this will have on other modules (I'm fairly new to programming), but matplotlib seems to work okay now. Ignorance is bliss... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 From noreply at sourceforge.net Fri Apr 7 15:26:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 06:26:29 -0700 Subject: [ python-Feature Requests-1433435 ] Use new expat version 2.0 Message-ID: Feature Requests item #1433435, was opened at 2006-02-17 10:16 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Use new expat version 2.0 Initial Comment: New expat version 2.0 is released. This one schould be used in the next python release (2.5). I checked the repository and feature request and there is no note about usage of new expat versions. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-07 15:26 Message: Logged In: YES user_id=1326842 There is a patch now: #1462338 upgrade pyexpat to expat 2.0.0 http://www.python.org/sf/1462338 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470 From noreply at sourceforge.net Fri Apr 7 16:58:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 07:58:10 -0700 Subject: [ python-Bugs-1465646 ] test_grp & test_pwd fail Message-ID: Bugs item #1465646, was opened at 2006-04-06 11:57 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp & test_pwd fail Initial Comment: test_grp and test_pwd fail on PC running Red Hat Enterprise Edition V4.2 with Python-2.4.3 and Python- 2.5a1. See attached file for test error messages. ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2006-04-07 15:58 Message: Logged In: YES user_id=200117 When I run the following script on the workstation import pwd, grp entries = pwd.getpwall() for e in entries: if e[2] < 0: print e entries = grp.getgrall() for e in entries: if e[2] < 0: print e -------------------------- I get this output: ('nobody', '*', -2, -2, '', '/', '') ('nogroup', '*', -2, []) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-07 11:13 Message: Logged In: YES user_id=21627 We should drop the tests in a selective manner. In this case, if -2 is in the password/group file, we should be able to find it: somebody might want to search by a gid value entered from a user, and that ought to work as well. rptownsend: could you investigate in more detail what's going on, on your system? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-06 19:34 Message: Logged In: YES user_id=89016 I'm prepared to throw out the fancy tests from test_pwd.py and test_grp.py. They don't buy us much anyway and basically test more the OS then the Python modules. (For related bugs see #779218, #962226 and #775964.) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-06 16:48 Message: Logged In: YES user_id=1126061 AFAIK getgrgid() doesn't handle negative integers very well (I can't even add a group with a negative gid on my NetBSD machine). ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 15:42 Message: Logged In: YES user_id=200117 The test workstation is getting its password and group info from NIS. The test workstation is running Red Hat Linux, but the NIS server is running HPUX 11i. I believe these are the entries causing the errors: lancaster:/etc > ypcat passwd | grep '-' nobody:*:-2:-2::/: lancaster:/etc > ypcat group | grep '-' nogroup:*:-2: ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 14:01 Message: Logged In: YES user_id=849994 Can you post the relevant part of /etc/passwd and /etc/group? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465646&group_id=5470 From noreply at sourceforge.net Fri Apr 7 17:40:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 08:40:35 -0700 Subject: [ python-Feature Requests-1208730 ] expat binding for XML_ParserReset Message-ID: Feature Requests item #1208730, was opened at 2005-05-25 22:37 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 Please note that this 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 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: expat binding for XML_ParserReset Initial Comment: XML_ParserReset is an expat parser method for resetting the parser to handle a new document. This keeps you from having to create a new parser for each document. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-07 17:40 Message: Logged In: YES user_id=1326842 That is patch #1244208. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 05:44 Message: Logged In: YES user_id=33168 See patch #1208730. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-31 08:12 Message: Logged In: YES user_id=322022 Forgot to mention I made the patch against current CVS. ---------------------------------------------------------------------- Comment By: John Eikenberry (zhar) Date: 2005-05-31 08:10 Message: Logged In: YES user_id=322022 Ok. I gave it a whirl. The patch is attached. If you have a moment, could you please look over it and let me know if I made any mistakes. Its a forward diff as recommended by the guidelines. I tried to follow them as much as possible. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-05-30 10:37 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this feature? Exposing more methods from Expat is a good idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1208730&group_id=5470 From noreply at sourceforge.net Fri Apr 7 18:24:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 09:24:01 -0700 Subject: [ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired Message-ID: Feature Requests item #1190596, was opened at 2005-04-27 00:10 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470 Please note that this 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 Submitted By: Tres Seaver (tseaver) Assigned to: Raymond Hettinger (rhettinger) Summary: calendar._firstweekday is too hard-wired Initial Comment: Long-running applications which need to make use of the 'calendar' module may need to present calendars to different users using the users' preferred settings. Currently, the two functions which rely on the locale-specific setting are too inflexible: they assume that the module-level global should always govern. The attached patch adds defaulted arguments to these functions, and uses the module-level global only where the caller does not pass in a value. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-07 18:24 Message: Logged In: YES user_id=1326842 I think that this request can now be closed, since an object oriented interface has been added in revision 43483 (see bug #947906). You can simply use multiple instances of Calendar class or its subclasses. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-29 17:04 Message: Logged In: YES user_id=127625 I somehow dropped the test patch on the floor. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 16:44 Message: Logged In: YES user_id=80475 Okay, I've got it from here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-29 16:32 Message: Logged In: YES user_id=31435 +1 from me. It's a very simple change, allowing callers to break dependence on a one-size-doesn't-fit-all global in a clear and thread-safe way. Doesn't break any existing code. Tiny slowdown in functions that aren't speed-critical anyway. The patch needs doc and test suite changes too, but what's here is fine by me so far as it goes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 00:51 Message: Logged In: YES user_id=80475 Tim, I'm -0 on this one. Do you have an opinion? Essentially, the OP wants an alternate, thread-safe interface to specifying firstweekday on a per-call basis. It can already be done with a wrapper function and a lock, so it is just a convenience issue. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 15:02 Message: Logged In: YES user_id=127625 WIth the patch, if you pass 'firstweekday' when calling 'monthcalendar' or 'weekheader', there is no race, and therefore no need to guard the global, because the global is ignored. Nothing else in the module depends on the value of that global except those two functions. I'm attaching a doctest which demonstrates the use case. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 14:36 Message: Logged In: YES user_id=80475 Write a simple wrapper to save and restore the global state: >>> def mymonthcalendar(year, month, first=None): if first is None: return monthcalendar(year, month) saved = firstweekday() setfirstweekday(first) rows = monthcalendar(year, month) setfirstweekday(saved) return rows That is essentially what the existing API is for. For a multi-threaded environment, you would need to add locks to th e critical section in the above code (the same would be true for your proposed patch). ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 14:24 Message: Logged In: YES user_id=127625 Different users of a long-running Python process may have different preferences for the first weekday; if the application tries to use the setfirstweekday() API for each of them, then they end up racing to set it. Making the option selectable per-call makes it side-effect free, and therefore more robust for multi-user applications. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 13:42 Message: Logged In: YES user_id=80475 I do not follow what can be done with your patch that cannot currently be done with setfirstweekday(). ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 13:06 Message: Logged In: YES user_id=127625 Aarrgh, what is the point of that silly checkbox, anyway? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 08:59 Message: Logged In: YES user_id=80475 The attachment didn't make it. Please try again and make sure to check-off the upload box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470 From noreply at sourceforge.net Fri Apr 7 18:41:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 09:41:00 -0700 Subject: [ python-Feature Requests-1190596 ] calendar._firstweekday is too hard-wired Message-ID: Feature Requests item #1190596, was opened at 2005-04-27 00:10 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470 Please note that this 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 Submitted By: Tres Seaver (tseaver) Assigned to: Raymond Hettinger (rhettinger) Summary: calendar._firstweekday is too hard-wired Initial Comment: Long-running applications which need to make use of the 'calendar' module may need to present calendars to different users using the users' preferred settings. Currently, the two functions which rely on the locale-specific setting are too inflexible: they assume that the module-level global should always govern. The attached patch adds defaulted arguments to these functions, and uses the module-level global only where the caller does not pass in a value. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-04-07 18:40 Message: Logged In: YES user_id=89016 Yes, with the new OO interface the examples from test_calendar.txt look like this: >>> import calendar >>> calendar.monthcalendar(2005, 4)[0] [0, 0, 0, 0, 1, 2, 3] >>> calendar.weekheader(1) 'M T W T F S S' >>> calendar.TextCalendar(0).monthdayscalendar(2005, 4)[0] [0, 0, 0, 0, 1, 2, 3] >>> calendar.TextCalendar(6).monthdayscalendar(2005, 4)[0] [0, 0, 0, 0, 0, 1, 2] >>> calendar.TextCalendar(0).formatweekheader(1) 'M T W T F S S' >>> calendar.TextCalendar(6).formatweekheader(1) 'S M T W T F S' Closing the feature request. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-07 18:24 Message: Logged In: YES user_id=1326842 I think that this request can now be closed, since an object oriented interface has been added in revision 43483 (see bug #947906). You can simply use multiple instances of Calendar class or its subclasses. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-29 17:04 Message: Logged In: YES user_id=127625 I somehow dropped the test patch on the floor. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 16:44 Message: Logged In: YES user_id=80475 Okay, I've got it from here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-29 16:32 Message: Logged In: YES user_id=31435 +1 from me. It's a very simple change, allowing callers to break dependence on a one-size-doesn't-fit-all global in a clear and thread-safe way. Doesn't break any existing code. Tiny slowdown in functions that aren't speed-critical anyway. The patch needs doc and test suite changes too, but what's here is fine by me so far as it goes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-29 00:51 Message: Logged In: YES user_id=80475 Tim, I'm -0 on this one. Do you have an opinion? Essentially, the OP wants an alternate, thread-safe interface to specifying firstweekday on a per-call basis. It can already be done with a wrapper function and a lock, so it is just a convenience issue. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 15:02 Message: Logged In: YES user_id=127625 WIth the patch, if you pass 'firstweekday' when calling 'monthcalendar' or 'weekheader', there is no race, and therefore no need to guard the global, because the global is ignored. Nothing else in the module depends on the value of that global except those two functions. I'm attaching a doctest which demonstrates the use case. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 14:36 Message: Logged In: YES user_id=80475 Write a simple wrapper to save and restore the global state: >>> def mymonthcalendar(year, month, first=None): if first is None: return monthcalendar(year, month) saved = firstweekday() setfirstweekday(first) rows = monthcalendar(year, month) setfirstweekday(saved) return rows That is essentially what the existing API is for. For a multi-threaded environment, you would need to add locks to th e critical section in the above code (the same would be true for your proposed patch). ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 14:24 Message: Logged In: YES user_id=127625 Different users of a long-running Python process may have different preferences for the first weekday; if the application tries to use the setfirstweekday() API for each of them, then they end up racing to set it. Making the option selectable per-call makes it side-effect free, and therefore more robust for multi-user applications. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 13:42 Message: Logged In: YES user_id=80475 I do not follow what can be done with your patch that cannot currently be done with setfirstweekday(). ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 2005-04-28 13:06 Message: Logged In: YES user_id=127625 Aarrgh, what is the point of that silly checkbox, anyway? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-28 08:59 Message: Logged In: YES user_id=80475 The attachment didn't make it. Please try again and make sure to check-off the upload box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190596&group_id=5470 From noreply at sourceforge.net Fri Apr 7 19:49:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 10:49:20 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Sat Apr 8 00:51:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 15:51:23 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-07 18: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=1466641&group_id=5470 Please note that this 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 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Sat Apr 8 03:35:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 18:35:47 -0700 Subject: [ python-Feature Requests-1039857 ] win32 silent installation: allow MAINDIR on command line Message-ID: Feature Requests item #1039857, was opened at 2004-10-04 12:23 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Matteo Gallivanoni (sigmud) Assigned to: Nobody/Anonymous (nobody) Summary: win32 silent installation: allow MAINDIR on command line Initial Comment: This request is related to my (false) "Bugs item #1038410" since it is by design and it won't be fixed I thought I could be suggested as a new feature. Request: Add a command line switch to be able to specify python install directory in silent installation mode in other word it should be something like this: Python-X.Y.Z.exe /s /d MAINDIR=C:\some_dir\python BTW: IIRC the windows wise installer configuration file is not provided into python cvs source tree so I can only suggest this google-groups thread as a hint: Newsgroups:wise.wise7.general Subject: "Passing the path name to a silent install. How?" Data:2000/01/17 ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-08 03:35 Message: Logged In: YES user_id=1326842 Starting with Python 2.4 it is possible to specify a TARGETDIR parameter to the msi installer. See http://www.python.org/download/releases/2.4/msi/ for more details. This feature request should be closed as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 From noreply at sourceforge.net Sat Apr 8 07:25:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 22:25:07 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-08 01:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 21:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 08:05:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Apr 2006 23:05:05 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-08 02:05 Message: Logged In: YES user_id=31435 As a sanity check on all those details, inside newPySSLObject() *(double *)((char *)&Sock->sock_timeout + 4) is in fact 30.0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 01:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 21:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 09:48:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 00:48:11 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-08 03:48 Message: Logged In: YES user_id=31435 Normal MS struct member alignment is definitely screwed up inside _ssl.c, but still don't know how that happens. sizeof this struct should be 16, but is reported as 12 when the source is inside _ssl.c: struct dummy { int a; double x; }; (note that in the details in previous comments, the double &Sock->sock_timeout was not 8-byte aligned in _ssl.c, but was in socketmodule.c). I don't see any MS packing pragmas in any of the OpenSSL .h files either. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 02:05 Message: Logged In: YES user_id=31435 As a sanity check on all those details, inside newPySSLObject() *(double *)((char *)&Sock->sock_timeout + 4) is in fact 30.0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 01:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 21:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 11:18:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 02:18:34 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 21:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-08 11:18 Message: Logged In: YES user_id=21627 The problem is that WIN32 isn't initially defined. WinSock2.h has this structure: #if !defined(WIN32) && !defined(_WIN64) #include #endif #include #if !defined(WIN32) && !defined(_WIN64) #include #endif Even though WIN32 is initially not defined, it is defined at the end of WinSock2.h, so that the poppack.h is not included. That leaves a pragma pack(push,4) on the pack stack. I haven't traced where exactly WIN32 is defined, but it probably comes from Ole2.h. Fixed in 43731 and 43732. Not sure whether anything needs to be done to the test suite. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 09:48 Message: Logged In: YES user_id=31435 Normal MS struct member alignment is definitely screwed up inside _ssl.c, but still don't know how that happens. sizeof this struct should be 16, but is reported as 12 when the source is inside _ssl.c: struct dummy { int a; double x; }; (note that in the details in previous comments, the double &Sock->sock_timeout was not 8-byte aligned in _ssl.c, but was in socketmodule.c). I don't see any MS packing pragmas in any of the OpenSSL .h files either. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 08:05 Message: Logged In: YES user_id=31435 As a sanity check on all those details, inside newPySSLObject() *(double *)((char *)&Sock->sock_timeout + 4) is in fact 30.0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 07:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-02 04:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-02 03:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 03:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 01:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 14:48:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 05:48:46 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-08 08:48 Message: Logged In: YES user_id=31435 Whoa -- good eye, Martin! Thank you. Looks like bugs all over the place. FYI, I later rehabilitated the disabled part of test_socket_ssl, and removed the Windows special-casing, in revs 43734 (trunk) and 43735 (2.4 branch). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-08 05:18 Message: Logged In: YES user_id=21627 The problem is that WIN32 isn't initially defined. WinSock2.h has this structure: #if !defined(WIN32) && !defined(_WIN64) #include #endif #include #if !defined(WIN32) && !defined(_WIN64) #include #endif Even though WIN32 is initially not defined, it is defined at the end of WinSock2.h, so that the poppack.h is not included. That leaves a pragma pack(push,4) on the pack stack. I haven't traced where exactly WIN32 is defined, but it probably comes from Ole2.h. Fixed in 43731 and 43732. Not sure whether anything needs to be done to the test suite. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 03:48 Message: Logged In: YES user_id=31435 Normal MS struct member alignment is definitely screwed up inside _ssl.c, but still don't know how that happens. sizeof this struct should be 16, but is reported as 12 when the source is inside _ssl.c: struct dummy { int a; double x; }; (note that in the details in previous comments, the double &Sock->sock_timeout was not 8-byte aligned in _ssl.c, but was in socketmodule.c). I don't see any MS packing pragmas in any of the OpenSSL .h files either. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 02:05 Message: Logged In: YES user_id=31435 As a sanity check on all those details, inside newPySSLObject() *(double *)((char *)&Sock->sock_timeout + 4) is in fact 30.0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 01:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 21:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 14:52:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 05:52:29 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 19:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-08 12:52 Message: Logged In: YES user_id=849994 Now one Windows buildbot turned red again since the timeout didn't raise socket.timeout but socket.error... :-| ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 12:48 Message: Logged In: YES user_id=31435 Whoa -- good eye, Martin! Thank you. Looks like bugs all over the place. FYI, I later rehabilitated the disabled part of test_socket_ssl, and removed the Windows special-casing, in revs 43734 (trunk) and 43735 (2.4 branch). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-08 09:18 Message: Logged In: YES user_id=21627 The problem is that WIN32 isn't initially defined. WinSock2.h has this structure: #if !defined(WIN32) && !defined(_WIN64) #include #endif #include #if !defined(WIN32) && !defined(_WIN64) #include #endif Even though WIN32 is initially not defined, it is defined at the end of WinSock2.h, so that the poppack.h is not included. That leaves a pragma pack(push,4) on the pack stack. I haven't traced where exactly WIN32 is defined, but it probably comes from Ole2.h. Fixed in 43731 and 43732. Not sure whether anything needs to be done to the test suite. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 07:48 Message: Logged In: YES user_id=31435 Normal MS struct member alignment is definitely screwed up inside _ssl.c, but still don't know how that happens. sizeof this struct should be 16, but is reported as 12 when the source is inside _ssl.c: struct dummy { int a; double x; }; (note that in the details in previous comments, the double &Sock->sock_timeout was not 8-byte aligned in _ssl.c, but was in socketmodule.c). I don't see any MS packing pragmas in any of the OpenSSL .h files either. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 06:05 Message: Logged In: YES user_id=31435 As a sanity check on all those details, inside newPySSLObject() *(double *)((char *)&Sock->sock_timeout + 4) is in fact 30.0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 05:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-02 02:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-02 01:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 01:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 23:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 15:00:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 06:00:18 -0700 Subject: [ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win Message-ID: Bugs item #1462352, was opened at 2006-03-31 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Georg Brandl (gbrandl) >Assigned to: Trent Mick (tmick) Summary: socket.ssl won't work together with socket.settimeout on Win Initial Comment: Symptoms: >>> import socket >>> s = socket.socket() >>> s.settimeout(30.0) >>> s.connect(("gmail.org", 995)) >>> ss = socket.ssl(s) Traceback (most recent call last): File "", line 1, in ? File "C:\python24\lib\socket.py", line 74, in ssl return _realssl(sock, keyfile, certfile) socket.sslerror: (2, 'The operation did not complete (read)') This does not occur on Unix, where test_socket_ssl.test_timeout runs smoothly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-08 09:00 Message: Logged In: YES user_id=31435 Yup, saw that, but I'd like input from Trent (it's his box): why is it timing out at all? 30 seconds is a huge blob of time, and none of the other buildbots are timing out. When I disabled test_socket_ssl's test_timeout, _all_ buildbot slaves were timing out (because gmail.org simply wasn't responding to anyone at the time). IOW, there may be a Win2K-specific bug in the Python implementation here (note that Trent's is the only Win2K slave we have). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-08 08:52 Message: Logged In: YES user_id=849994 Now one Windows buildbot turned red again since the timeout didn't raise socket.timeout but socket.error... :-| ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 08:48 Message: Logged In: YES user_id=31435 Whoa -- good eye, Martin! Thank you. Looks like bugs all over the place. FYI, I later rehabilitated the disabled part of test_socket_ssl, and removed the Windows special-casing, in revs 43734 (trunk) and 43735 (2.4 branch). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-08 05:18 Message: Logged In: YES user_id=21627 The problem is that WIN32 isn't initially defined. WinSock2.h has this structure: #if !defined(WIN32) && !defined(_WIN64) #include #endif #include #if !defined(WIN32) && !defined(_WIN64) #include #endif Even though WIN32 is initially not defined, it is defined at the end of WinSock2.h, so that the poppack.h is not included. That leaves a pragma pack(push,4) on the pack stack. I haven't traced where exactly WIN32 is defined, but it probably comes from Ole2.h. Fixed in 43731 and 43732. Not sure whether anything needs to be done to the test suite. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 03:48 Message: Logged In: YES user_id=31435 Normal MS struct member alignment is definitely screwed up inside _ssl.c, but still don't know how that happens. sizeof this struct should be 16, but is reported as 12 when the source is inside _ssl.c: struct dummy { int a; double x; }; (note that in the details in previous comments, the double &Sock->sock_timeout was not 8-byte aligned in _ssl.c, but was in socketmodule.c). I don't see any MS packing pragmas in any of the OpenSSL .h files either. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 02:05 Message: Logged In: YES user_id=31435 As a sanity check on all those details, inside newPySSLObject() *(double *)((char *)&Sock->sock_timeout + 4) is in fact 30.0. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 01:25 Message: Logged In: YES user_id=31435 I did a data breakpoint on the 8 bytes in the sock_timeout member, and it never triggered: nothing stores anything there to change 30.0 to 0.0. Instead, socketmodule.c and _ssl.c have different views of where the members of a PySocketSockObject live. WRT socketmodule.c sock_settimeout's `s`, and _ssl.c newPySSLObject's `Sock` (which are the same object in the test case), the debugger agrees about the addresses at which these members live: &s->_ob_next 0x0096c3e8 &s->_ob_prev 0x0096c3ec &s->ob_refcnt 0x0096c3f0 &s->ob_type 0x0096c3f4 &s->sock_fd 0x0096c3f8 &s->sock_family 0x0096c3fc &s->sock_type 0x0096c400 &s->sock_proto 0x0096c404 &s->sock_addr 0x0096c408 &s->errorhandler 0x0096c488 But there's a radical disconnect about where it thinks sock_timeout lives: &s->sock_timeout 0x0096c490 &Sock->sock_timeout 0x0096c48c Indeed, printf("%d\n", sizeof(PySocketSockObject)); displays different results: socketmodule.c: 176 _ssl.c: 172 I'm unclear about why. Doing printf("%d\n", sizeof(sock_addr_t)); prints 128 in both modules, so there's not an obvious difference there. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 21:08 Message: Logged In: YES user_id=31435 BTW, does anyone understand why this part of my first comment was true?: """ check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. """ How did s->sock_timeout become 0? s.settimeout(30.0) was called, and the same s was passed to socket.ssl(). I don't understand this at all: >>> s.connect(("gmail.org", 995)) >>> s.gettimeout() 30.0 >>> s._sock >>> s._sock.gettimeout() 30.0 >>> ss = socket.ssl(s) but a breakpoint in newPySSLObject() right there shows that Sock->sock_timeout is 0.0. HTF did that happen? If I poke 30.0 (under the debugger) into Sock->sock_timeout at the start of newPySSLObject(), the constructor finishes unexceptionally. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-01 20:57 Message: Logged In: YES user_id=31435 gmail.com happened to respond when I tried it today, so I can confirm (alas) that the patch at http://pastebin.com/633224 made no difference to the outcome on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 20:36 Message: Logged In: YES user_id=31435 Because the s.connect(("gmail.org", 995)) line started timing out on all (non-Windows) buildbot slaves some hours ago, causing all test runs to fail, I disabled test_timeout on all boxes for now (on trunk & on 2.4 branch). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:23 Message: Logged In: YES user_id=31435 Note that this is a problem in 2.4 and trunk. The sample code worked fine earlier today if (and only if) I left out the .settimeout() call. Note that buildbot test runs are failing in trunk and 2.4 branch now on non-Windows boxes, because the s.connect(("gmail.org", 995)) line is timing out (the new test is disabled on Windows, and that's why the Windows buildbots are still passing). At the moment, that's timing out on my Windows box too. We clearly need a more reliable net address to connect to. On Bug Day IRC, "arekm" last asked that I try this patch on Windows: http://pastebin.com/633224 Unfortunately, I haven't been able to get beyond the s.connect(("gmail.org", 995)) line since then, so still don't know whether that helps. Nothing else did ;-) On Windows, in newPySSLObject(), "ret = SSL_connect(self->ssl);" returns -1 "err = SSL_get_error(self->ssl, ret);" returns 2 "if (err == SSL_ERROR_WANT_READ)" triggers. check_socket_and_wait_for_timeout() takes the "else if (s->sock_timeout == 0.0)" path and and returns SOCKET_IS_NONBLOCKING. newPySSLObject() breaks out of its loop then, and does "PySSL_SetError(self, ret); goto fail;" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470 From noreply at sourceforge.net Sat Apr 8 19:28:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 10:28:52 -0700 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-04-01 10:23 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nick Coghlan (ncoghlan) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 03:28 Message: Logged In: YES user_id=1038590 I can fix it so that the runpy module lines are only masked out when the module is invoked implicitly via the -m switch by giving the C code a private entry point (_run_module_as_main) that catches exceptions and prints the filtered traceback before doing sys.exit(-1). I'll make sure to add some tests to test_cmd_line to verify the updated behaviour. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 21:12 Message: Logged In: YES user_id=1038590 I'd forgotten about SF's current "no email when assigned a bug" feature. . . I'm inclined to agree with Guido that it could be tricky to get rid of these without also masking legitimate traceback info for import errors (e.g. if the PEP 302 emulation machinery blows up rather than returning None the way it is meant to when it can't find a loader for the module). OTOH, I don't like the current output for an import errror, either: C:\>C:\python25\python.exe -m junk Traceback (most recent call last): File "C:\Python25\Lib\runpy.py", line 410, in run_module raise ImportError("No module named " + mod_name) ImportError: No module named junk So I'll look into it - if it is suspected that runpy is at fault for a problem with running a script, then there's two easy ways to get the full traceback: C:\>C:\python25\python.exe -m runpy junk C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-06 10:45 Message: Logged In: YES user_id=6380 I'm not so sure. Who looks at the top of the traceback anyway? And it might hide clues about problems caused by runpy.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Sat Apr 8 20:17:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 11:17:01 -0700 Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections Message-ID: Feature Requests item #1453341, was opened at 2006-03-19 05:52 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 Please note that this 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: Closed >Resolution: Rejected Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: ====== atomic = sys.setatomicexecution(mode) try: print "Executing critical section" finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 04:17 Message: Logged In: YES user_id=1038590 Raymond brought this idea up on python-dev at the time of the c.l.p discussion - it was rejected on the basis that thread synchronisation tools (Queues and Locks) are provided for a reason. Python level access to the Global Interpreter Lock is neither necessary nor desirable. Avoiding the tools provided to permit threading to work correctly and then finding that threaded code doesn't work as desired really shouldn't be surprising. FWIW, Python 2.5 aims to make normal locking easier to use by permitting: from __future__ import with_statement from threading import Lock sync_lock = Lock() def my_func(*args, **kwds): with sync_lock: # Only one thread at a time can enter this section # regardless of IO or anything else # This section, on the other hand, is a free-for-all If you genuinely have to avoid normal thread synchronisation primitives, you can abuse (and I really do mean abuse) the interpreter's import lock for this purpose: imp.acquire_lock() try: print 'critical section' finally: imp.release_lock() Or even: @contextlib.contextmanager def CriticalSection() imp.acquire_lock() try: yield finally: imp.release_lock() with CriticalSection(): print 'critical section' ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-21 01:28 Message: Logged In: YES user_id=972995 ... only PyEval_RestoreThread with the harder execution level in its tstate ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-21 01:24 Message: Logged In: YES user_id=972995 thus the GIL could simply have a harder state 2 : "locked hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ? Only PyEval_RestoreThread gets the lock again after PyEval_SaveThread. Robert ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2006-03-20 22:17 Message: Logged In: YES user_id=884167 - sys.setcheckinterval(sys.maxint) does not prevent thread switching when doing IO, does it? There is no way that I know of to prevent thread switching in this situation. - When calling back into Python from C Code, there is no way to tell Python not to relinquish the GIL; such an option could be useful for some C code, because the GIL provides a "global critical section". Martin ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-19 07:54 Message: Logged In: YES user_id=972995 or: >>> atomic = sys.acquireatomicexecution(mode) >>> try: ... print 'critical section' ... finally: ... atomic.release() >>> with sys.acquireatomicexecution(mode): ... print 'critical section' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 From noreply at sourceforge.net Sat Apr 8 20:34:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 11:34:13 -0700 Subject: [ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections Message-ID: Feature Requests item #1453341, was opened at 2006-03-19 05:52 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 Please note that this 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: Closed Resolution: Rejected Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: ====== atomic = sys.setatomicexecution(mode) try: print "Executing critical section" finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 04:34 Message: Logged In: YES user_id=1038590 On the other changes you suggest (which Raymond didn't bring up on python-dev): Python can't formally define as atomic any operations that may execute arbitrary Python code, as the interpreter cannot control what that code may do. All of the examples you give are in that category. Slowing down the common cases (unthreaded code and Queue-based threaded code) by adding internal locking to every data structure is also considered highly undesirable. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 04:17 Message: Logged In: YES user_id=1038590 Raymond brought this idea up on python-dev at the time of the c.l.p discussion - it was rejected on the basis that thread synchronisation tools (Queues and Locks) are provided for a reason. Python level access to the Global Interpreter Lock is neither necessary nor desirable. Avoiding the tools provided to permit threading to work correctly and then finding that threaded code doesn't work as desired really shouldn't be surprising. FWIW, Python 2.5 aims to make normal locking easier to use by permitting: from __future__ import with_statement from threading import Lock sync_lock = Lock() def my_func(*args, **kwds): with sync_lock: # Only one thread at a time can enter this section # regardless of IO or anything else # This section, on the other hand, is a free-for-all If you genuinely have to avoid normal thread synchronisation primitives, you can abuse (and I really do mean abuse) the interpreter's import lock for this purpose: imp.acquire_lock() try: print 'critical section' finally: imp.release_lock() Or even: @contextlib.contextmanager def CriticalSection() imp.acquire_lock() try: yield finally: imp.release_lock() with CriticalSection(): print 'critical section' ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-21 01:28 Message: Logged In: YES user_id=972995 ... only PyEval_RestoreThread with the harder execution level in its tstate ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-21 01:24 Message: Logged In: YES user_id=972995 thus the GIL could simply have a harder state 2 : "locked hard for PyEval_AcquireThread/PyEval_AcquireLock/.." ? Only PyEval_RestoreThread gets the lock again after PyEval_SaveThread. Robert ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2006-03-20 22:17 Message: Logged In: YES user_id=884167 - sys.setcheckinterval(sys.maxint) does not prevent thread switching when doing IO, does it? There is no way that I know of to prevent thread switching in this situation. - When calling back into Python from C Code, there is no way to tell Python not to relinquish the GIL; such an option could be useful for some C code, because the GIL provides a "global critical section". Martin ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-19 07:54 Message: Logged In: YES user_id=972995 or: >>> atomic = sys.acquireatomicexecution(mode) >>> try: ... print 'critical section' ... finally: ... atomic.release() >>> with sys.acquireatomicexecution(mode): ... print 'critical section' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453341&group_id=5470 From noreply at sourceforge.net Sat Apr 8 22:23:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 13:23:08 -0700 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-03-31 19:23 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nick Coghlan (ncoghlan) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-08 16:23 Message: Logged In: YES user_id=31435 I see no reason to bother with this -- it adds complexity, and I don't see any real benefit. What's bad about having runpy show up in the traceback, given that code in runpy.py actually _is_ in the call stack? Why try to hide the truth of it? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-08 13:28 Message: Logged In: YES user_id=1038590 I can fix it so that the runpy module lines are only masked out when the module is invoked implicitly via the -m switch by giving the C code a private entry point (_run_module_as_main) that catches exceptions and prints the filtered traceback before doing sys.exit(-1). I'll make sure to add some tests to test_cmd_line to verify the updated behaviour. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 07:12 Message: Logged In: YES user_id=1038590 I'd forgotten about SF's current "no email when assigned a bug" feature. . . I'm inclined to agree with Guido that it could be tricky to get rid of these without also masking legitimate traceback info for import errors (e.g. if the PEP 302 emulation machinery blows up rather than returning None the way it is meant to when it can't find a loader for the module). OTOH, I don't like the current output for an import errror, either: C:\>C:\python25\python.exe -m junk Traceback (most recent call last): File "C:\Python25\Lib\runpy.py", line 410, in run_module raise ImportError("No module named " + mod_name) ImportError: No module named junk So I'll look into it - if it is suspected that runpy is at fault for a problem with running a script, then there's two easy ways to get the full traceback: C:\>C:\python25\python.exe -m runpy junk C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-05 20:45 Message: Logged In: YES user_id=6380 I'm not so sure. Who looks at the top of the traceback anyway? And it might hide clues about problems caused by runpy.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Sun Apr 9 00:16:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 15:16:53 -0700 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-03-31 19:23 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 Please note that this 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 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nick Coghlan (ncoghlan) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-08 18:16 Message: Logged In: YES user_id=6380 I'm with Tim. Please close w/o action. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-08 16:23 Message: Logged In: YES user_id=31435 I see no reason to bother with this -- it adds complexity, and I don't see any real benefit. What's bad about having runpy show up in the traceback, given that code in runpy.py actually _is_ in the call stack? Why try to hide the truth of it? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-08 13:28 Message: Logged In: YES user_id=1038590 I can fix it so that the runpy module lines are only masked out when the module is invoked implicitly via the -m switch by giving the C code a private entry point (_run_module_as_main) that catches exceptions and prints the filtered traceback before doing sys.exit(-1). I'll make sure to add some tests to test_cmd_line to verify the updated behaviour. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 07:12 Message: Logged In: YES user_id=1038590 I'd forgotten about SF's current "no email when assigned a bug" feature. . . I'm inclined to agree with Guido that it could be tricky to get rid of these without also masking legitimate traceback info for import errors (e.g. if the PEP 302 emulation machinery blows up rather than returning None the way it is meant to when it can't find a loader for the module). OTOH, I don't like the current output for an import errror, either: C:\>C:\python25\python.exe -m junk Traceback (most recent call last): File "C:\Python25\Lib\runpy.py", line 410, in run_module raise ImportError("No module named " + mod_name) ImportError: No module named junk So I'll look into it - if it is suspected that runpy is at fault for a problem with running a script, then there's two easy ways to get the full traceback: C:\>C:\python25\python.exe -m runpy junk C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-05 20:45 Message: Logged In: YES user_id=6380 I'm not so sure. Who looks at the top of the traceback anyway? And it might hide clues about problems caused by runpy.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Sun Apr 9 04:20:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 8 Apr 2006 19:20:26 -0700 Subject: [ python-Bugs-892939 ] Race condition in popen2 Message-ID: <200604090220.k392KQBR015190@sc8-sf-db2-new-b.sourceforge.net> Bugs item #892939, was opened at 02/08/04 09:31 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470 Please note that this 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.3 >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Ken McNeil (kenmcneil) Assigned to: Neal Norwitz (nnorwitz) Summary: Race condition in popen2 Initial Comment: The "fix" for bug #761888 created a race condition in Popen3 . The interaction between wait and _cleanup is the root of the problem. def wait(self): """Wait for and return the exit status of the child process.""" if self.sts < 0: pid, sts = os.waitpid(self.pid, 0) if pid == self.pid: self.sts = sts return self.sts def _cleanup(): for inst in _active[:]: inst.poll() In wait, between the check of self.sts and the call to os.waitpid a new Popen3 object can be created in another thread which will trigger a call to _cleanup. Since the call to _cleanup polls the process, when the thread running wait starts back up again it will try to poll the process using os.waitpid, which will throw an OSError because os.waitpid has already been called for the PID indirectly in _cleanup. A work around is for the caller of wait to catch the OSError and check the sts field, and if sts is non-negative then the OSError is most likely because of this problem and can be ignored. However, sts is undocumented and should probably stay that way. My suggestion is that the patch that added _active, _cleanup, and all be removed and a more suitable mechanism for fixing bug #761888 be found. As it has been said in the discussion of bug #761888, magically closing FDs is not a "good thing". It seems to me that surrounding the call to os.fork with a try/except, and closing the pipes in the except, would be suitable but I don't know how this would interact with a failed call to fork, therefore I wont provide a patch. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 04/08/06 19:20 Message: Logged In: YES user_id=1312539 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: Neal Norwitz (nnorwitz) Date: 03/24/06 20:56 Message: Logged In: YES user_id=33168 Martin and I worked out a patch which should solve this problem and it was committed. For more info see bug 1183780, If this does not solve the problem, change the status from pending to open. Otherwise, this bug report should close automatically in a couple of weeks since it's pending. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 03/23/06 00:47 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470 From noreply at sourceforge.net Sun Apr 9 04:20:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 8 Apr 2006 19:20:26 -0700 Subject: [ python-Bugs-998246 ] Popen3.poll race condition Message-ID: <200604090220.k392KQil015198@sc8-sf-db2-new-b.sourceforge.net> Bugs item #998246, was opened at 07/26/04 12:14 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 Please note that this 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 Submitted By: Tres Seaver (tseaver) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen3.poll race condition Initial Comment: poll() swallows all IOErrors, including ENOCHILD; if the child process exits before poll is called, then an applications which loops on poll() will never exit. I am working around this (against Python 2.3.3) via the following: try: pid, status = os.waitpid(proc.pid, os.WNOHANG) except os.error, e: if e.errno == 10: # ENOCHILD result = 0 else: raise else: if pid == proc.pid: result = status where 'proc' is an instance of Popen3. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 04/08/06 19:20 Message: Logged In: YES user_id=1312539 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: Neal Norwitz (nnorwitz) Date: 03/24/06 20:59 Message: Logged In: YES user_id=33168 Tres, Martin and I worked out a patch that we thinks solves the problem. It's checked in. See the other bug report for more info. If you don't believe the patch will fix your problem, change the status from pending to open. Otherwise, this bug should automatically close in a couple of weeks. ---------------------------------------------------------------------- Comment By: Tres Seaver (tseaver) Date: 03/23/06 04:21 Message: Logged In: YES user_id=127625 1183780 is indeed a similar bug, although he reports it against Popen4 rather than Popen3. His patch needs to be modified to re-raise errors which are not ENOCHILD, however. I no longer have accees to either the application or the machine where I found this issue, and hence can't verify that the patch fixes the code which triggered the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 03/23/06 00:45 Message: Logged In: YES user_id=33168 I believe this is basically a duplicate of 1183780. There is a patch attached there. Can you verify if it fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470 From noreply at sourceforge.net Sun Apr 9 04:44:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 19:44:22 -0700 Subject: [ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions Message-ID: Feature Requests item #1462486, was opened at 2006-04-01 10:23 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nick Coghlan (ncoghlan) Summary: Scripts invoked by -m should trim exceptions Initial Comment: Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like: Traceback (most recent call last): File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module filename, loader, alter_sys) File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code mod_name, mod_fname, mod_loader) File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code exec code in run_globals File "D:\Development\modules\test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body This should probably be trimmed to: Traceback (most recent call last): File "test25.py", line 53, in raise GeneratorExit('body') GeneratorExit: body to match when a script is invoked by filename. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 12:44 Message: Logged In: YES user_id=1038590 Done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-09 08:16 Message: Logged In: YES user_id=6380 I'm with Tim. Please close w/o action. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-09 06:23 Message: Logged In: YES user_id=31435 I see no reason to bother with this -- it adds complexity, and I don't see any real benefit. What's bad about having runpy show up in the traceback, given that code in runpy.py actually _is_ in the call stack? Why try to hide the truth of it? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 03:28 Message: Logged In: YES user_id=1038590 I can fix it so that the runpy module lines are only masked out when the module is invoked implicitly via the -m switch by giving the C code a private entry point (_run_module_as_main) that catches exceptions and prints the filtered traceback before doing sys.exit(-1). I'll make sure to add some tests to test_cmd_line to verify the updated behaviour. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-07 21:12 Message: Logged In: YES user_id=1038590 I'd forgotten about SF's current "no email when assigned a bug" feature. . . I'm inclined to agree with Guido that it could be tricky to get rid of these without also masking legitimate traceback info for import errors (e.g. if the PEP 302 emulation machinery blows up rather than returning None the way it is meant to when it can't find a loader for the module). OTOH, I don't like the current output for an import errror, either: C:\>C:\python25\python.exe -m junk Traceback (most recent call last): File "C:\Python25\Lib\runpy.py", line 410, in run_module raise ImportError("No module named " + mod_name) ImportError: No module named junk So I'll look into it - if it is suspected that runpy is at fault for a problem with running a script, then there's two easy ways to get the full traceback: C:\>C:\python25\python.exe -m runpy junk C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-06 10:45 Message: Logged In: YES user_id=6380 I'm not so sure. Who looks at the top of the traceback anyway? And it might hide clues about problems caused by runpy.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470 From noreply at sourceforge.net Sun Apr 9 05:32:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 20:32:33 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-08 08:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this 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 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 13:32 Message: Logged In: YES user_id=1038590 Is including two if clauses with a single for clause really meant to be legal? *goes and looks at language reference* Wow. What a strange way to write "and". . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Sun Apr 9 06:07:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Apr 2006 21:07:22 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-07 18:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this 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 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-09 00:07 Message: Logged In: YES user_id=31435 The whittled-down version looks ridiculous, but the original wasn't quite such an affront to beauty :-) It's really no stranger than allowing pure "if" statements to nest, and it would be more painful to contort the grammar to disallow it (I haven't looked at the 2.5 parser, but it was very surprising to me that it didn't allow it!). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-08 23:32 Message: Logged In: YES user_id=1038590 Is including two if clauses with a single for clause really meant to be legal? *goes and looks at language reference* Wow. What a strange way to write "and". . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Sun Apr 9 12:06:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 03:06:40 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by atler_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 12:29:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 03:29:25 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 12:46:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 03:46:31 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 08:47 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 10:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 10:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 10:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 05:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-04 22:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 12:51:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 03:51:31 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by atler_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 14:14:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 05:14:55 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 18:47 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 22:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 20:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 20:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 20:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 20:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 15:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 08:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 15:05:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 06:05:07 -0700 Subject: [ python-Bugs-1467201 ] size_t warnings on OSX 10.3 Message-ID: Bugs item #1467201, was opened at 2006-04-09 23:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: size_t warnings on OSX 10.3 Initial Comment: Building on my mac, running sam% uname -a Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc sam% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) I get a whole pile of warnings, like the following: Python/exceptions.c: In function `UnicodeEncodeError__str__': Python/exceptions.c:1340: warning: signed size_t format, Py_ssize_t arg (arg 4) Python/exceptions.c:1349: warning: signed size_t format, Py_ssize_t arg (arg 3) Python/exceptions.c:1349: warning: signed size_t format, int arg (arg 4) Attached is full build log. config.status says "HAVE_SSIZE_T" is defined. ${ac_dA}HAVE_SSIZE_T${ac_dB}HAVE_SSIZE_T${ac_dC}1${ac_dD} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 From noreply at sourceforge.net Sun Apr 9 15:09:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 06:09:24 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 01:09 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Sun Apr 9 15:48:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 06:48:24 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by atler_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 16:50:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 07:50:14 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-07 22:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this 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 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 14:50 Message: Logged In: YES user_id=849994 Haha. The second "if" is seen as the beginning of a conditional expression, so return [fn for fn in os.listdir(dir) if fn if fn else fn] works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-09 04:07 Message: Logged In: YES user_id=31435 The whittled-down version looks ridiculous, but the original wasn't quite such an affront to beauty :-) It's really no stranger than allowing pure "if" statements to nest, and it would be more painful to contort the grammar to disallow it (I haven't looked at the 2.5 parser, but it was very surprising to me that it didn't allow it!). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 03:32 Message: Logged In: YES user_id=1038590 Is including two if clauses with a single for clause really meant to be legal? *goes and looks at language reference* Wow. What a strange way to write "and". . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Sun Apr 9 16:57:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 07:57:54 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-07 22:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this 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 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 14:57 Message: Logged In: YES user_id=849994 Changing list_if: 'if' test [list_iter] to list_if: 'if' old_test [list_iter] solves the problem. Conditionals must then be enclosed in parens. Generator expressions are also affected. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 14:50 Message: Logged In: YES user_id=849994 Haha. The second "if" is seen as the beginning of a conditional expression, so return [fn for fn in os.listdir(dir) if fn if fn else fn] works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-09 04:07 Message: Logged In: YES user_id=31435 The whittled-down version looks ridiculous, but the original wasn't quite such an affront to beauty :-) It's really no stranger than allowing pure "if" statements to nest, and it would be more painful to contort the grammar to disallow it (I haven't looked at the 2.5 parser, but it was very surprising to me that it didn't allow it!). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 03:32 Message: Logged In: YES user_id=1038590 Is including two if clauses with a single for clause really meant to be legal? *goes and looks at language reference* Wow. What a strange way to write "and". . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Sun Apr 9 17:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 08:30:48 -0700 Subject: [ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags Message-ID: Bugs item #1465838, was opened at 2006-04-07 02:53 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-10 01:30 Message: Logged In: YES user_id=29957 Hm. We need to detect if we're on HP/UX, of course. Is this option for all versions? And I assume it's only for the HP compiler, not gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 From noreply at sourceforge.net Sun Apr 9 20:42:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 11:42:02 -0700 Subject: [ python-Bugs-1467309 ] open should default to binary mode on windows Message-ID: Bugs item #1467309, was opened at 2006-04-09 13: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=1467309&group_id=5470 Please note that this 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 Submitted By: Adam Hupp (hupp) Assigned to: Nobody/Anonymous (nobody) Summary: open should default to binary mode on windows Initial Comment: On windows the open() function defaults to reading files in text mode. To get a binary mode file I need to append a "b" to the mode string. I think this is an unnessary platform inconsistency. Twice now I've had hard to track down bugs because I was reading a file in text mode and should have been using binary. This is a wart, IMO. I'd like to suggest that the default open mode on windows be made binary, with an option to change it to text if desired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467309&group_id=5470 From noreply at sourceforge.net Sun Apr 9 22:58:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 13:58:18 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sun Apr 9 23:02:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 14:02:34 -0700 Subject: [ python-Bugs-1467201 ] size_t warnings on OSX 10.3 Message-ID: Bugs item #1467201, was opened at 2006-04-09 15:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: size_t warnings on OSX 10.3 Initial Comment: Building on my mac, running sam% uname -a Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc sam% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) I get a whole pile of warnings, like the following: Python/exceptions.c: In function `UnicodeEncodeError__str__': Python/exceptions.c:1340: warning: signed size_t format, Py_ssize_t arg (arg 4) Python/exceptions.c:1349: warning: signed size_t format, Py_ssize_t arg (arg 3) Python/exceptions.c:1349: warning: signed size_t format, int arg (arg 4) Attached is full build log. config.status says "HAVE_SSIZE_T" is defined. ${ac_dA}HAVE_SSIZE_T${ac_dB}HAVE_SSIZE_T${ac_dC}1${ac_dD} ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 23:02 Message: Logged In: YES user_id=21627 Can you find out what Py_ssize_t is eventually defined as (i.e. how is ssize_t defined); how is size_t defined (looking at the preprocessor output might help)? What type would the compiler accept for a signed size_t format? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 From noreply at sourceforge.net Sun Apr 9 23:18:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 14:18:07 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 23:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Mon Apr 10 02:43:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 17:43:54 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-08 00:51 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Thomas Wouters (twouters) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-10 02:43 Message: Logged In: YES user_id=34209 Yeah, this is definately caused by the PEP 308 patch, so I guess the error is mine (but don't tell anyone.) Unless someone beats me to it, I'll fix it and add a test tomorrow (but please don't fix it without checking in some tests.) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 16:57 Message: Logged In: YES user_id=849994 Changing list_if: 'if' test [list_iter] to list_if: 'if' old_test [list_iter] solves the problem. Conditionals must then be enclosed in parens. Generator expressions are also affected. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 16:50 Message: Logged In: YES user_id=849994 Haha. The second "if" is seen as the beginning of a conditional expression, so return [fn for fn in os.listdir(dir) if fn if fn else fn] works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-09 06:07 Message: Logged In: YES user_id=31435 The whittled-down version looks ridiculous, but the original wasn't quite such an affront to beauty :-) It's really no stranger than allowing pure "if" statements to nest, and it would be more painful to contort the grammar to disallow it (I haven't looked at the 2.5 parser, but it was very surprising to me that it didn't allow it!). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 05:32 Message: Logged In: YES user_id=1038590 Is including two if clauses with a single for clause really meant to be legal? *goes and looks at language reference* Wow. What a strange way to write "and". . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Mon Apr 10 02:45:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 17:45:46 -0700 Subject: [ python-Bugs-1467309 ] open should default to binary mode on windows Message-ID: Bugs item #1467309, was opened at 2006-04-09 20:42 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467309&group_id=5470 Please note that this 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 Submitted By: Adam Hupp (hupp) Assigned to: Nobody/Anonymous (nobody) Summary: open should default to binary mode on windows Initial Comment: On windows the open() function defaults to reading files in text mode. To get a binary mode file I need to append a "b" to the mode string. I think this is an unnessary platform inconsistency. Twice now I've had hard to track down bugs because I was reading a file in text mode and should have been using binary. This is a wart, IMO. I'd like to suggest that the default open mode on windows be made binary, with an option to change it to text if desired. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-10 02:45 Message: Logged In: YES user_id=34209 Sorry, that would break too much existing code. For Python 3.0, where it is okay to break existing code, opening a file will be explicitly text (with automatic decoding to Unicode) or binary (where reading fetches you bytes, instead of a string), and the matter will be solved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467309&group_id=5470 From noreply at sourceforge.net Mon Apr 10 03:21:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 18:21:51 -0700 Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3 Message-ID: Bugs item #1467450, was opened at 2006-04-10 11: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=1467450&group_id=5470 Please note that this 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 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on OSX 10.3 Initial Comment: test test_ctypes failed -- Traceback (most recent call last): File "/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py", line 30, in test_load cdll.load(libc_name) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 153, in _load return self.load_library(pathname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlcompat: unable to open this file with RTLD_LOCAL This happens both with and without the patch in r43748. Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc GCC version: Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470 From noreply at sourceforge.net Mon Apr 10 03:56:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 18:56:02 -0700 Subject: [ python-Bugs-1467201 ] size_t warnings on OSX 10.3 Message-ID: Bugs item #1467201, was opened at 2006-04-09 09:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: size_t warnings on OSX 10.3 Initial Comment: Building on my mac, running sam% uname -a Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc sam% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) I get a whole pile of warnings, like the following: Python/exceptions.c: In function `UnicodeEncodeError__str__': Python/exceptions.c:1340: warning: signed size_t format, Py_ssize_t arg (arg 4) Python/exceptions.c:1349: warning: signed size_t format, Py_ssize_t arg (arg 3) Python/exceptions.c:1349: warning: signed size_t format, int arg (arg 4) Attached is full build log. config.status says "HAVE_SSIZE_T" is defined. ${ac_dA}HAVE_SSIZE_T${ac_dB}HAVE_SSIZE_T${ac_dC}1${ac_dD} ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-09 21:56 Message: Logged In: YES user_id=31435 Since Anthony reported that config.status says HAVE_SSIZE_T is defined, doesn't #ifdef HAVE_SSIZE_T typedef ssize_t Py_ssize_t; in pyport.h rule here? Pretty bizarre, if so :-) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 17:02 Message: Logged In: YES user_id=21627 Can you find out what Py_ssize_t is eventually defined as (i.e. how is ssize_t defined); how is size_t defined (looking at the preprocessor output might help)? What type would the compiler accept for a signed size_t format? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 From noreply at sourceforge.net Mon Apr 10 04:02:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 19:02:28 -0700 Subject: [ python-Bugs-1467309 ] open should default to binary mode on windows Message-ID: Bugs item #1467309, was opened at 2006-04-09 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467309&group_id=5470 Please note that this 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: Not a Bug Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Adam Hupp (hupp) Assigned to: Nobody/Anonymous (nobody) Summary: open should default to binary mode on windows Initial Comment: On windows the open() function defaults to reading files in text mode. To get a binary mode file I need to append a "b" to the mode string. I think this is an unnessary platform inconsistency. Twice now I've had hard to track down bugs because I was reading a file in text mode and should have been using binary. This is a wart, IMO. I'd like to suggest that the default open mode on windows be made binary, with an option to change it to text if desired. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-09 22:02 Message: Logged In: YES user_id=31435 Closing this. It can't be changed now without breaking mountains of code, and it's debatable that changing it would be a good idea even if not (Python follows C exactly in this respect now -- but there's no need to debate it since it ain't gonna happen before Python 3 regardless). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-04-09 20:45 Message: Logged In: YES user_id=34209 Sorry, that would break too much existing code. For Python 3.0, where it is okay to break existing code, opening a file will be explicitly text (with automatic decoding to Unicode) or binary (where reading fetches you bytes, instead of a string), and the matter will be solved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467309&group_id=5470 From noreply at sourceforge.net Mon Apr 10 08:30:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Apr 2006 23:30:40 -0700 Subject: [ python-Bugs-1467201 ] size_t warnings on OSX 10.3 Message-ID: Bugs item #1467201, was opened at 2006-04-09 15:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: size_t warnings on OSX 10.3 Initial Comment: Building on my mac, running sam% uname -a Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc sam% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) I get a whole pile of warnings, like the following: Python/exceptions.c: In function `UnicodeEncodeError__str__': Python/exceptions.c:1340: warning: signed size_t format, Py_ssize_t arg (arg 4) Python/exceptions.c:1349: warning: signed size_t format, Py_ssize_t arg (arg 3) Python/exceptions.c:1349: warning: signed size_t format, int arg (arg 4) Attached is full build log. config.status says "HAVE_SSIZE_T" is defined. ${ac_dA}HAVE_SSIZE_T${ac_dB}HAVE_SSIZE_T${ac_dC}1${ac_dD} ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 08:30 Message: Logged In: YES user_id=21627 Sure. The question then is: what is ssize_t, as opposed to size_t. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-10 03:56 Message: Logged In: YES user_id=31435 Since Anthony reported that config.status says HAVE_SSIZE_T is defined, doesn't #ifdef HAVE_SSIZE_T typedef ssize_t Py_ssize_t; in pyport.h rule here? Pretty bizarre, if so :-) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 23:02 Message: Logged In: YES user_id=21627 Can you find out what Py_ssize_t is eventually defined as (i.e. how is ssize_t defined); how is size_t defined (looking at the preprocessor output might help)? What type would the compiler accept for a signed size_t format? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467201&group_id=5470 From noreply at sourceforge.net Mon Apr 10 09:01:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 00:01:31 -0700 Subject: [ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Message-ID: Bugs item #1463043, was opened at 2006-04-02 16:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Martin v. L??wis (loewis) Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3 Initial Comment: I built Python-2.4.3 from source on SUSE 9.3 and get the following error for test_minidom.py /usr/local/src/Python-2.4.3: ./python Lib/test/test_minidom.py Failed Test Test Failed: testAltNewline Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 427, in testAltNewline confirm(domstr == str.replace("\n", "\r\n")) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed testEncodings - encoding EURO SIGN Test Failed: testEncodings Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 891, in testEncodings "testEncodings - encoding EURO SIGN") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed After replaceChild() Test Failed: testPatch1094164 Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 1137, in testPatch1094164 confirm(e.parentNode is elem, "After replaceChild()") File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception Failed Test Test Failed: testWriteXML Traceback (most recent call last): File "Lib/test/test_minidom.py", line 1384, in ? func() File "Lib/test/test_minidom.py", line 420, in testWriteXML confirm(str == domstr) File "Lib/test/test_minidom.py", line 28, in confirm raise Exception Exception **** Check for failures in these tests: testAltNewline testEncodings testPatch1094164 testWriteXML ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 09:01 Message: Logged In: YES user_id=21627 It's no surprise that the error didn't occur in 2.5a1: the PyXML-0.8.4 installation on rptownsend's machine was for 2.4; the 2.5 sandbox won't see 2.4's xmlplus. Even if PyXML was installed on 2.5, the test suite would still refer to xmlcore, thus bypassing PyXML. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-07 12:07 Message: Logged In: YES user_id=200117 I added a few print statements to the tests - see attached file py_243.txt for the results while running on Python- 2.4.3 ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-06 14:31 Message: Logged In: YES user_id=200117 Interestingly, the error doesn't occur with Python-2.5a1 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 08:27 Message: Logged In: YES user_id=33168 Martin maintains PyXML AFAIK. Maybe he has some ideas. I suspect this might be even worse in 2.5. Element Tree was added and there was a name change. Some of those things still need to be addressed. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-03 15:37 Message: Logged In: YES user_id=200117 Hi Neal, I've just built 2.4.3 on a Red Hat Enterpeise Edition WS V4.2 machine and this gives the same error. I've had this vague feeling that I've seen something like this before, but couldn't find anything when I searched the tracker... I've now realised that the error is due to a conflict with PyXML-0.8.4 which was already installed on both machines. If I rename the ../site_packages/_xmlplus directory to a different name then the error goes away (on the Red Hat machine at least, the SUSE machine is at home). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 07:37 Message: Logged In: YES user_id=33168 Thanks for letting us know about where the regression occurred. Can you do a little more debugging to try to find the cause and some ideas about how to fix it? I'm not sure that any developer runs on a system that exhibits this error. So it will probably be very difficult for us to figure it out since we can't reproduce it. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2006-04-02 16:28 Message: Logged In: YES user_id=200117 I've just retested with earlier versions. No error with Python-2.4.1 Similar error with Python-2.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470 From noreply at sourceforge.net Mon Apr 10 09:59:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 00:59:19 -0700 Subject: [ python-Feature Requests-1039857 ] win32 silent installation: allow MAINDIR on command line Message-ID: Feature Requests item #1039857, was opened at 2004-10-04 12:23 Message generated for change (Settings changed) made by sigmud You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matteo Gallivanoni (sigmud) Assigned to: Nobody/Anonymous (nobody) Summary: win32 silent installation: allow MAINDIR on command line Initial Comment: This request is related to my (false) "Bugs item #1038410" since it is by design and it won't be fixed I thought I could be suggested as a new feature. Request: Add a command line switch to be able to specify python install directory in silent installation mode in other word it should be something like this: Python-X.Y.Z.exe /s /d MAINDIR=C:\some_dir\python BTW: IIRC the windows wise installer configuration file is not provided into python cvs source tree so I can only suggest this google-groups thread as a hint: Newsgroups:wise.wise7.general Subject: "Passing the path name to a silent install. How?" Data:2000/01/17 ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-08 03:35 Message: Logged In: YES user_id=1326842 Starting with Python 2.4 it is possible to specify a TARGETDIR parameter to the msi installer. See http://www.python.org/download/releases/2.4/msi/ for more details. This feature request should be closed as fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 From noreply at sourceforge.net Mon Apr 10 10:35:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 01:35:32 -0700 Subject: [ python-Bugs-1036406 ] Tix.Grid widgets not implemented yet Message-ID: Bugs item #1036406, was opened at 2004-09-28 20:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036406&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. L??wis (loewis) Summary: Tix.Grid widgets not implemented yet Initial Comment: This code fails at the .pack method (.grid, .place too): >>> import Tix >>> r=Tix.Tk() >>> g=Tix.Grid() >>> g.pack() Traceback (most recent call last): File "", line 1, in ? File "d:\PY.24\lib\lib-tk\Tkinter.py", line 1692, in pack_configure self.tk.call( _tkinter.TclError: bad window path name ".8257088" Tix Grids work though as shown here: >>> r.tk.call('tixGrid', '.g1') '.g1' >>> r.tk.call('pack', '.g1') '' >>> r.tk.call('.g1', 'set', '0', '0', '-text', 'hello!') '' I intend to supply a patch, but I need to first understand better how Tkinter works (and therefore Tix.py); I create a bug so that anyone willing might help provide Python users with an often requested widget. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 10:35 Message: Logged In: YES user_id=21627 This is fixed with patch #1462222. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036406&group_id=5470 From noreply at sourceforge.net Mon Apr 10 12:33:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 03:33:54 -0700 Subject: [ python-Bugs-1467619 ] Header.decode_header eats up spaces Message-ID: Bugs item #1467619, was opened at 2006-04-10 12:33 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=1467619&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Goutelle (mgoutell) Assigned to: Nobody/Anonymous (nobody) Summary: Header.decode_header eats up spaces Initial Comment: The Header.decode_header function eats up spaces in non-encoded part of a header. See the following source: # -*- coding: iso-8859-1 -*- from email.Header import Header, decode_header h = Header('Essai ', None) h.append('????', 'iso-8859-1') print h print decode_header(h) This prints: Essai =?iso-8859-1?q?=E9=E8?= [('Test', None), ('\xe9\xe8', 'iso-8859-1')] This should print: Essai =?iso-8859-1?q?=E9=E8?= [('Test ', None), ('\xe9\xe8', 'iso-8859-1')] ^ This space disappears This appears in Python 2.3 but the source code of the function didn't change in 2.4 so the same problem should still exist. Bug "[ 1372770 ] email.Header should preserve original FWS" may be linked to that one although I'm not sure this is exactly the same. This patch (not extensively tested though) seems to solve this problem: --- /usr/lib/python2.3/email/Header.py 2005-09-05 00:20:03.000000000 +0200 +++ Header.py 2006-04-10 12:27:27.000000000 +0200 @@ -90,7 +90,7 @@ continue parts = ecre.split(line) while parts: - unenc = parts.pop(0).strip() + unenc = parts.pop(0).rstrip() if unenc: # Should we continue a long line? if decoded and decoded[-1][1] is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470 From noreply at sourceforge.net Mon Apr 10 12:44:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 03:44:32 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Mon Apr 10 14:00:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 05:00:40 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 14:00 Message: Logged In: YES user_id=21627 The code is fine, but it lacks documentation. There should be some way to learn about --with-system-ffi, preferably by either reading ./configure --help output, or reading README. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Mon Apr 10 14:27:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 05:27:22 -0700 Subject: [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Martin v. L??wis (loewis) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 14:27 Message: Logged In: YES user_id=21627 Right: about about this patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 22:52 Message: Logged In: YES user_id=849994 Ping! ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Mon Apr 10 14:40:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 05:40:41 -0700 Subject: [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-30 02:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Martin v. L??wis (loewis) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 14:40 Message: Logged In: YES user_id=21627 This was fixed with said patch in r45232. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 11:34 Message: Logged In: YES user_id=1188172 See patch #1429775. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-11-25 22:53 Message: Logged In: YES user_id=876734 I only see one possible issue with the patch. I exploited the existing BLDLIBRARY macro. It says '-L.' on linux. Which is fine for the initial 'make', but not too great when the Makefile gets copied to the install dir. The comments in the config dir leave me thinking that there would be a Makefile.pre in there, but there isn't. Just a Makefile. The RUNSHARED macro ends up set back to where I built it, not to where I installed it. If some process would fix RUNSHARED, it could also fix BLDSHARED. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-11-25 22:27 Message: Logged In: YES user_id=876734 I submitted a set of patches that work for the initial build. I think I'll need more for the tools that are used later, I'm moving on to that next. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-24 23:16 Message: Logged In: YES user_id=21627 1) Basically, you lose. If you don't want to build a module as a shared library, you can build it statically, through Modules/Setup. If you absolutely don't want to build a module at all, you edit setup.py, and modify disabled_module_list. If you don't want to edit disabled_module_list, you build the module, and delete it when done. 2) Using /usr/local/lib could be replaced, but I would consider this out of scope of this change. Feel free to submit a separate patch. Make sure that the alternative patch manages to pick up shared libraries in all cases where it finds them today. 3) 'cvs annotate' reveals that this was added in setup.py 1.100. 'cvs log' reveals that this was added in response to python.org/sf/589427, where the Debian maintainer complains that /usr/include is added to the list of -I options, even though the compiler already has /usr/include in its search list. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-11-23 21:44 Message: Logged In: YES user_id=876734 I'm running into issues trying to come up with a clean version of this. I'd like to know what you think of some of these before I try to port what I've got into 2.4 and come up with patches. 1) setup.py seems to have no way to be selective about which modules to build. What if I don't want to try (and then fail make install) to build, for example, ssl? 2) setup.py makes assumptions about pathnames. It always puts /usr/local/lib into the build path. On a 64-bit solaris or HP system, this can lead to a mess, if the 64 bit libraries are somewhere else. 3) There is an existing provision to add additional libs to the build in setup.py, but it's disabled if the prefix is /usr. Why? I have this feeling that someone had a plan here that I'm too obtuse to make out which would offer a shorter path to a solution then I'm getting tangled up in, for managing the build of these modules. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-10-31 14:42 Message: Logged In: YES user_id=21627 You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-31 13:22 Message: Logged In: YES user_id=876734 To turn my patches into things that anyone else would want, I need to know what to put in the -L that will be required. At the time we're building the main python distro, that's straightforward. When a user builds an individual module, is there a sensible path relative to PYTHONHOME I can use? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-10-31 11:05 Message: Logged In: YES user_id=21627 Please do provide patches. Take into account that modules may be built either with distutils, or through Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Mon Apr 10 14:52:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 05:52:39 -0700 Subject: [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 15:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-10 12:52 Message: Logged In: YES user_id=849994 Looks fine from my POV. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 12:27 Message: Logged In: YES user_id=21627 Right: about about this patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 21:52 Message: Logged In: YES user_id=849994 Ping! ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 17:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:39 Message: Logged In: YES user_id=21627 How about the attached patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-06 20:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Mon Apr 10 15:03:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 06:03:23 -0700 Subject: [ python-Bugs-1467619 ] Header.decode_header eats up spaces Message-ID: Bugs item #1467619, was opened at 2006-04-10 10:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Goutelle (mgoutell) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Header.decode_header eats up spaces Initial Comment: The Header.decode_header function eats up spaces in non-encoded part of a header. See the following source: # -*- coding: iso-8859-1 -*- from email.Header import Header, decode_header h = Header('Essai ', None) h.append('????', 'iso-8859-1') print h print decode_header(h) This prints: Essai =?iso-8859-1?q?=E9=E8?= [('Test', None), ('\xe9\xe8', 'iso-8859-1')] This should print: Essai =?iso-8859-1?q?=E9=E8?= [('Test ', None), ('\xe9\xe8', 'iso-8859-1')] ^ This space disappears This appears in Python 2.3 but the source code of the function didn't change in 2.4 so the same problem should still exist. Bug "[ 1372770 ] email.Header should preserve original FWS" may be linked to that one although I'm not sure this is exactly the same. This patch (not extensively tested though) seems to solve this problem: --- /usr/lib/python2.3/email/Header.py 2005-09-05 00:20:03.000000000 +0200 +++ Header.py 2006-04-10 12:27:27.000000000 +0200 @@ -90,7 +90,7 @@ continue parts = ecre.split(line) while parts: - unenc = parts.pop(0).strip() + unenc = parts.pop(0).rstrip() if unenc: # Should we continue a long line? if decoded and decoded[-1][1] is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470 From noreply at sourceforge.net Mon Apr 10 15:55:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 06:55:51 -0700 Subject: [ python-Feature Requests-1465406 ] Allowing the definition of constants Message-ID: Feature Requests item #1465406, was opened at 2006-04-06 01:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 15:55 Message: Logged In: YES user_id=21627 The problem is that declaring the value assignment const doesn't help. Consider this: from math import pi def area(r): return r*r*pi pi = 4 print area(10) So even though math.pi might be declared as a constant, hard-coding its value into the function area would break this program - the value of the variable pi might change not change inside math, but it might change where it is imported. ---------------------------------------------------------------------- Comment By: Chris Wilson (ciw42) Date: 2006-04-06 23:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-06 01:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 From noreply at sourceforge.net Mon Apr 10 15:59:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 06:59:43 -0700 Subject: [ python-Feature Requests-1425256 ] Support for MSVC 7 and MSVC8 in msvccompiler Message-ID: Feature Requests item #1425256, was opened at 2006-02-06 15:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1425256&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: dlm (davidlukas) Assigned to: Nobody/Anonymous (nobody) Summary: Support for MSVC 7 and MSVC8 in msvccompiler Initial Comment: Hi, I tried to build the "ctypes-0.9.6" packages from source with Microsoft Visual Studio 8 (2005). I realized that in module "distutils" of Python 2.4.1 both VC7 and VC8 compilers are not supported at all (only VC6). I took a glance at distutils at Python 2.4.2 but also there no VC8 is supported. I tried to figure out where I should extend the compiler detection, but the whole file "msvccompiler.py" seems to me like a big hack. I've wrote some code, to get VC8 working on my machine (set right pathes to Include- and Lib-Directories and to the binaries), but I don't think it's redistributable. What do you think of detecting the right MS-Compiler like this: def detectCompiler() : detectVC6() detectVC7() detectVC8() and hiding the code for each particular version of VC in a separate function. I don't think MS is following a streight upwards compatibility strategy. Also ther should be a way, to select on compiler, when multiple compilers are detected. I saw the --compiler=whatever switch, but did not found any documentation on it. I've got both versions (VC7 and VC8) installed on my machine. So I can try out different detection routines if you want. Another problem with VC8 is cross-compiling, since ther e are different library-directories for different platforms (AMD64, x86, Itanium, Win32, ...). Also here I see big deficits in the distutil-module at the moment. Best regards David ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 15:59 Message: Logged In: YES user_id=21627 Why do you think only VC6 is supported in distutils? It works just fine with VC7.1 (Visual Studio .NET 2003). Don't try to build Python extension modules with VS 2005 (aka VC8), unless you know precisely what you are doing: by doing so, you link different versions of msvcrt; this might cause crashes. In general, you must use the same C compiler that Python was built with. There is not much we can do about this (it's a Microsoft limitation), so I'm rejecting the request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1425256&group_id=5470 From noreply at sourceforge.net Mon Apr 10 16:07:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 07:07:18 -0700 Subject: [ python-Feature Requests-960454 ] old/new class documentation Message-ID: Feature Requests item #960454, was opened at 2004-05-26 00:33 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 Please note that this 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 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: old/new class documentation Initial Comment: The distributed documentation refers to old and new-style classes, but they do not appear in the index, and the difference is not explained. (Users who ask are referred to documentation on www.python.org, which is not currently shipped with the default distrubution.) As best I understand it, the only differences are: (1) New-style classes inherit from object. Because of this inheritance, new-style classes have a few extra capabilities, such as descriptors and super. (2) Method Resolution Order can be different in cases of multiple inheritance. (3) New style classes take precedence over old-style classes when doing rich comparison. (4) If rich comparison fails, numeric coercion will be attempted if -- and only if -- at least one of the objects is an old-style class. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-10 16:07 Message: Logged In: YES user_id=1326842 This seems like a duplicate of bug #960340, which was closed when section New-style and classic classes was added to the Python Reference Manual (see http://docs.python.org/dev/ref/node33.html). ---------------------------------------------------------------------- Comment By: Edward Diener (eldiener) Date: 2004-08-02 01:53 Message: Logged In: YES user_id=490593 New style classes, with all their new attributes, member functions, static methods, and class methods, need to be documented in the official Python distribution. Included in this is the explanation of metaclasses and how to use them. Essentially Guido's paper on new style classes, reworked to fit within the existing documentation framework, should be added to the official documantation.. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 17:21 Message: Logged In: YES user_id=764593 Found a new difference -- you can't assign to the __bases__ or __name__ of a new-style class, and you can't usually assign to it's __class__. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 16:05 Message: Logged In: YES user_id=764593 Given that the differences are almost -- but not entirely -- extra options for new-style classes, the language lawyer section on classes (ref/7.6) might be a good location. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 From noreply at sourceforge.net Mon Apr 10 16:55:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 07:55:36 -0700 Subject: [ python-Bugs-1460493 ] Why not drop the _active list? Message-ID: Bugs item #1460493, was opened at 2006-03-29 07:16 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:55 Message: Logged In: YES user_id=1276121 see patch #1467770 ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-05 08:27 Message: Logged In: YES user_id=1276121 the implementation in 2.5 of popen2 seems good if you or astrand could patch subprocess.py accordingly, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-30 16:31 Message: Logged In: YES user_id=21627 attila-cheops, please read the 2.5 version of popen2. popen2 now only adds processes to _active in __del__, not in __init__, so the problem with the application still wanting to wait/poll is solved. Multiple threads simultaneously isn't a problem, since it is (or should be) harmless to invoke poll on a process that has already been waited for. For only one of the poll calls, the wait will actually succeed, and that should be the one that removes it from the _active list. The same strategy should be applied to subprocess. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:17 Message: Logged In: YES user_id=1276121 also #1214859 is interesting, has a patch ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:06 Message: Logged In: YES user_id=1276121 the same problem probably exists in popen2.py there _active is also used so if something is fixed in subprocess.py, it should probably also be fixed in popen2.py ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:04 Message: Logged In: YES user_id=1276121 what happens if you are doing a _cleanup (iterating over a copy of _active) in multiple threads? can it not happen then that you clean up a process 2 times? thread 1 starts a _cleanup: makes a copy of _active[:] and starts polling thread 2 starts a _cleanup: makes a copy of _active[:] and starts polling thread 1 encounters a finished process and removes it from _active[] thread 2 does not know the process is removed, finds the same process finished and tries to remove it from _active but this fails, because thread 1 removed it already so the action of cleaning up should maybe be serialized if 1 thread is doing it, the other one should block everyone who needs this can of course patch the subprocess.py file, but shouldn't this be fixed in the library? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-30 07:43 Message: Logged In: YES user_id=33168 If you always called wait() the _active list isn't beneficial to you. However, many people do not call wait and the _active list provides a mechanism to cleanup zombied children. This is important for many users. If you need thread safely, you can handle the locking yourself before calling poll()/wait(). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-29 20:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 From noreply at sourceforge.net Mon Apr 10 16:56:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 07:56:00 -0700 Subject: [ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads Message-ID: Bugs item #1183780, was opened at 2005-04-15 14:27 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-24 08:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 07:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-24 07:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 05:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-24 00:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection: If __del__ would put unwaited objects into _active, rather than __init__, it would not happen that _cleanup polls a pid which a thread still intends to wait for. In fact, it would be sufficient to only put the pid into _active (avoiding the need for resurrection). If then a thread calls poll explicitly, and another calls wait, they deserve to lose (with ECHILD). I would claim the same error exists if part of the application calls os.wait[3,4](), and another calls .wait later - they also deserve the exception. With that approach, I don't think further thread synchronization would be needed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-23 08:41 Message: Logged In: YES user_id=33168 The attached patch fixes the problem for me. It also addresses another issue where wait could be called from outside the popen2 module. I'm not sure this is the best solution. I'm not sure there really is a good solution. Perhaps it's best to allow an exception to be raised? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&group_id=5470 From noreply at sourceforge.net Mon Apr 10 16:57:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 07:57:48 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this 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 Submitted By: cheops (atila-cheops) Assigned to: Peter ? strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- >Comment By: cheops (atila-cheops) Date: 2006-04-10 14:57 Message: Logged In: YES user_id=1276121 see patch #1467770 ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:50 Message: Logged In: YES user_id=1488657 > Simply list operations such as remove() and append() are > thread safe, OK, my apologies... I did not know. I did some more tests. On Linux, I found lots of: File "./subprocess.py", line 428, in call return Popen(*args, **kwargs).wait() File "./subprocess.py", line 1023, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes The try...except solution does not handle this (since we are in the "posix" section). In my opinion, the call to _cleanup() in Popen.__init__() is useless (it just checks if older processes have stopped when a new one is started. I cannot see why it could be mandatory) and it is the root of this bug. I commented it out (line 506) and retried my tests on Linux & Windows plateforms: I had no exception at all. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2006-03-29 05:11 Message: Logged In: YES user_id=344921 >I think accesses to _active should be serialized in a >thread-safe way. _active could be a Queue (from the Queue >module) for example Simply list operations such as remove() and append() are thread safe, so there should be no need for a Queue. Also, a Queue cannot be used since the subprocess module needs to be compatible with Python 2.2. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-28 23:17 Message: Logged In: YES user_id=1488657 I am running into the same problem on a Windows 2k/XP plateform with a multi-threaded application. It occurs randomly. It has never appened (yet) on a Linux plateform. I think accesses to _active should be serialized in a thread-safe way. _active could be a Queue (from the Queue module) for example. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-25 08:10 Message: Logged In: YES user_id=1434251 Wouldn't it be best to completely remove any references to "_active" and "_cleanup"? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-01-25 07:08 Message: Logged In: YES user_id=1276121 As suggested by astrand adding a try ... except clause in the file subprocess.py did the job I had to add that try ... except clause in 2 places if you look in the file there are 2 instances were list.remove(x) occurs unprotected. try: list.remove(x) except: pass I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three needed the patch. Hope this helps. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Mon Apr 10 17:58:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 08:58:24 -0700 Subject: [ python-Bugs-1460493 ] Why not drop the _active list? Message-ID: Bugs item #1460493, was opened at 2006-03-29 09:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 17:58 Message: Logged In: YES user_id=21627 This was fixed with said patch. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch #1467770 ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-05 10:27 Message: Logged In: YES user_id=1276121 the implementation in 2.5 of popen2 seems good if you or astrand could patch subprocess.py accordingly, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-30 18:31 Message: Logged In: YES user_id=21627 attila-cheops, please read the 2.5 version of popen2. popen2 now only adds processes to _active in __del__, not in __init__, so the problem with the application still wanting to wait/poll is solved. Multiple threads simultaneously isn't a problem, since it is (or should be) harmless to invoke poll on a process that has already been waited for. For only one of the poll calls, the wait will actually succeed, and that should be the one that removes it from the _active list. The same strategy should be applied to subprocess. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 10:17 Message: Logged In: YES user_id=1276121 also #1214859 is interesting, has a patch ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 10:06 Message: Logged In: YES user_id=1276121 the same problem probably exists in popen2.py there _active is also used so if something is fixed in subprocess.py, it should probably also be fixed in popen2.py ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-03-30 10:04 Message: Logged In: YES user_id=1276121 what happens if you are doing a _cleanup (iterating over a copy of _active) in multiple threads? can it not happen then that you clean up a process 2 times? thread 1 starts a _cleanup: makes a copy of _active[:] and starts polling thread 2 starts a _cleanup: makes a copy of _active[:] and starts polling thread 1 encounters a finished process and removes it from _active[] thread 2 does not know the process is removed, finds the same process finished and tries to remove it from _active but this fails, because thread 1 removed it already so the action of cleaning up should maybe be serialized if 1 thread is doing it, the other one should block everyone who needs this can of course patch the subprocess.py file, but shouldn't this be fixed in the library? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-30 09:43 Message: Logged In: YES user_id=33168 If you always called wait() the _active list isn't beneficial to you. However, many people do not call wait and the _active list provides a mechanism to cleanup zombied children. This is important for many users. If you need thread safely, you can handle the locking yourself before calling poll()/wait(). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-29 22:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 15:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 From noreply at sourceforge.net Mon Apr 10 18:04:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 09:04:38 -0700 Subject: [ python-Bugs-1214859 ] subprocess auto-reaps children Message-ID: Bugs item #1214859, was opened at 2005-06-04 18:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Mattias Engdeg?rd (yorick) Assigned to: Peter ? strand (astrand) Summary: subprocess auto-reaps children Initial Comment: The subprocess module automatically reaps child processes, by maintaining a list of instances which is traversed each time a new Popen instance is created. Apparently this was originally intended to avoid large number of zombie processes to accrete in the system if the programmer is lazy and does not wait for them properly, but it can cause problems when the programmer wants greater control. In particular, it's not possible to use the pid from a subprocess.Popen instance, since it may already have disappeared. For instance, it makes it difficult to use os.wait() to wait for several child processes at the same time. The solution is simple: Add an option that disables the auto-reaper for a Popen instance. This makes everyone happy: existing code is unaffected, the programmer who wants to control her processes herself is allowed to do that, and the documentation is improved to help avoiding a nasty bug. A patch was posted to the patch tracker as number 1187312. I suggest it for inclusion into the next release. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 18:04 Message: Logged In: YES user_id=21627 Thanks for the report. This is now fixed in r45234. ---------------------------------------------------------------------- Comment By: Andrew Waters (awaters) Date: 2006-02-02 09:37 Message: Logged In: YES user_id=1418249 May want to add a lock in order that auto reaping can happen in addition to the use of waitpid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&group_id=5470 From noreply at sourceforge.net Mon Apr 10 21:39:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 12:39:08 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 21: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=1467929&group_id=5470 Please note that this 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 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Mon Apr 10 21:44:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 12:44:41 -0700 Subject: [ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags Message-ID: Bugs item #1465838, was opened at 2006-04-06 09:53 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=71407 > Hm. We need to detect if we're on HP/UX, of course. Is > this option for all versions? I guess so since it seems very fundamental, but I am not sure. I alerted Boris Gubenko to this problem report. I hope he will help out. > And I assume it's only for the HP compiler, not gcc? I don't know. I imagine gcc has similar issues since it does link with the same -lpthread eventually. Note that the machine I used is publically accessible: http://www.testdrive.hp.com/ After you register on the web: telnet td176.testdrive.hp.com gcc 3.4.3 is installed. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:30 Message: Logged In: YES user_id=29957 Hm. We need to detect if we're on HP/UX, of course. Is this option for all versions? And I assume it's only for the HP compiler, not gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 From noreply at sourceforge.net Mon Apr 10 22:12:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 13:12:34 -0700 Subject: [ python-Bugs-1467952 ] os.listdir on Linux returns empty list on some errors Message-ID: Bugs item #1467952, was opened at 2006-04-10 15: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=1467952&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gary Stiehr (gstiehr) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on Linux returns empty list on some errors Initial Comment: os.listdir() (defined in the posix_listdir() function on line 1449 of Modules/posixmodule.c in the Python-2.4.3 source distribution) does not check for an error condition when it calls the readdir() system call on line 1665 of posixmodule.c. According to the readdir(3) man page included the Scientific Linux 4.2 (based off of Red Hat Enterprise Linux 4 sources): The readdir() function returns a pointer to a dirent structure, or NULL if an error occurs or end-of-file is reached. It seems that the posix_listdir() function assumes that NULL can only mean end-of-file. Therefore, in the situation where readdir() returns NULL due to some error, such as an I/O Error, posix_listdir() ends the while loop started at line 1665 and goes to the closedir() call at line 1702. This results in an os.listdir() call returning an empty list (as if the directory had no contents) instead of raising an exception. This error was noticed because we performed an ls in a particular directory and it returned with an I/O error. I was then writing a python script to monitor for this condition when I found that the os.listdir() in this directory returned an empty list instead of an I/O error. This behavior was noticed using Python 2.3.4; I looked at the latest (as of 2006-04-07) stable release source (Python 2.4.3) to investigate and to provide the details in this bug report. I also took a quick look at the most recent 2.5.x code and although the posix_listdir function has changed, it still appears as if it would return an empty list if the readdir() call returns NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467952&group_id=5470 From noreply at sourceforge.net Mon Apr 10 22:28:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 13:28:37 -0700 Subject: [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 22:28 Message: Logged In: YES user_id=21627 Committed as r45239. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-10 14:52 Message: Logged In: YES user_id=849994 Looks fine from my POV. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 14:27 Message: Logged In: YES user_id=21627 Right: about about this patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 22:52 Message: Logged In: YES user_id=849994 Ping! ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Mon Apr 10 22:45:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 13:45:57 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-04-10 22:45 Message: Logged In: YES user_id=60903 documentation added. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 14:00 Message: Logged In: YES user_id=21627 The code is fine, but it lacks documentation. There should be some way to learn about --with-system-ffi, preferably by either reading ./configure --help output, or reading README. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Mon Apr 10 23:24:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 14:24:20 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by atler_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Tue Apr 11 00:28:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 15:28:29 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 00:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Tue Apr 11 01:11:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 16:11:11 -0700 Subject: [ python-Bugs-214033 ] re incompatibility in sre Message-ID: Bugs item #214033, was opened at 2000-09-11 08:24 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Martin v. L??wis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-04-10 23:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2000-10-01 18:13 Message: Yes, it is still broken in 2.0b2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 04:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 From noreply at sourceforge.net Tue Apr 11 01:11:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 16:11:56 -0700 Subject: [ python-Bugs-214033 ] re incompatibility in sre Message-ID: Bugs item #214033, was opened at 2000-09-11 08:24 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Martin v. L??wis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-04-10 23:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2000-10-01 18:13 Message: Yes, it is still broken in 2.0b2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 04:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 From noreply at sourceforge.net Tue Apr 11 01:58:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 16:58:12 -0700 Subject: [ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags Message-ID: Bugs item #1465838, was opened at 2006-04-06 09:53 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-10 16:58 Message: Logged In: YES user_id=71407 Boris Gubenko from HP provides this information: Hi Ralf, the -mt option sets -lpthread link option and defines various macros related to multithreading, including _REENTRANT macro. It must be specified when compiling/linking a multithreaded application. The -mt option is supported in latest aCC compilers, including the aCC V6 compiler (available on IA64 only). I'm not sure if -mt is supported in old aCC V3 compiler available on PA-RISC only, but since Python cannot be compiled with this compiler, this question is, probably, moot. If configuration script wants to be selective about the aCC compiler version, it can check __HP_aCC macro predefined by the compiler and apply '-mt' if __HP_aCC >= 60000. As for the gnu compiler, I think, that the equivalent of '-mt' would be '-pthreads' (for cxx on Tru64, it would be '-pthread'). I don't know how to reply to the post on Python forum you've referred me to. I guess, I'd need to register for an account. I can do it if you want me to. Or you can just post it on my behalf. Thanks, Boris ----- Original Message ----- From: "Ralf W. Grosse-Kunstleve" To: Cc: Sent: Sunday, April 09, 2006 2:11 PM Subject: HP-UX Python configure Hi Boris, Could you please help out here? https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 Especially with this question: "Is this option for all versions?" Thank you in advance! Cheers, Ralf ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=71407 > Hm. We need to detect if we're on HP/UX, of course. Is > this option for all versions? I guess so since it seems very fundamental, but I am not sure. I alerted Boris Gubenko to this problem report. I hope he will help out. > And I assume it's only for the HP compiler, not gcc? I don't know. I imagine gcc has similar issues since it does link with the same -lpthread eventually. Note that the machine I used is publically accessible: http://www.testdrive.hp.com/ After you register on the web: telnet td176.testdrive.hp.com gcc 3.4.3 is installed. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:30 Message: Logged In: YES user_id=29957 Hm. We need to detect if we're on HP/UX, of course. Is this option for all versions? And I assume it's only for the HP compiler, not gcc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 From noreply at sourceforge.net Tue Apr 11 02:08:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 17:08:03 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 01:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 00:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 21:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 11 07:13:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 22:13:15 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 14:17 Message generated for change (Comment added) made by vnainar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: nomind (vnainar) Date: 2006-04-11 10:43 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 03:58 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-11 02:54 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 02:28 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 19:18 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 17:44 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 16:21 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 16:16 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 15:59 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:36 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 11:08 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 03:46 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Tue Apr 11 07:22:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 22:22:14 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 02:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 23:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 11 07:32:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 22:32:24 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 07:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 00:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Tue Apr 11 08:01:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 23:01:28 -0700 Subject: [ python-Bugs-1468223 ] Hitting CTRL-C while in a loop closes IDLE on cygwin Message-ID: Bugs item #1468223, was opened at 2006-04-11 09:01 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=1468223&group_id=5470 Please note that this 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 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Hitting CTRL-C while in a loop closes IDLE on cygwin Initial Comment: Try the following: >>> while 1: print 1 1 1 1 ... Not hit CTRL-C IDLE will close When hitting CTRL-C when IDLE is idle (huh), the regular KeyboardInterrupt is shown This happens on Cygwin (but not on Linux) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468223&group_id=5470 From noreply at sourceforge.net Tue Apr 11 08:29:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 23:29:39 -0700 Subject: [ python-Bugs-1468231 ] test_grp test_pwd fail on Linux Message-ID: Bugs item #1468231, was opened at 2006-04-11 09: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=1468231&group_id=5470 Please note that this 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 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp test_pwd fail on Linux Initial Comment: Python 2.5a1, SUSE Linux test_grp test_pwd fails when running "make test" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468231&group_id=5470 From noreply at sourceforge.net Tue Apr 11 08:51:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Apr 2006 23:51:43 -0700 Subject: [ python-Bugs-1467952 ] os.listdir on Linux returns empty list on some errors Message-ID: Bugs item #1467952, was opened at 2006-04-10 20:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467952&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary Stiehr (gstiehr) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on Linux returns empty list on some errors Initial Comment: os.listdir() (defined in the posix_listdir() function on line 1449 of Modules/posixmodule.c in the Python-2.4.3 source distribution) does not check for an error condition when it calls the readdir() system call on line 1665 of posixmodule.c. According to the readdir(3) man page included the Scientific Linux 4.2 (based off of Red Hat Enterprise Linux 4 sources): The readdir() function returns a pointer to a dirent structure, or NULL if an error occurs or end-of-file is reached. It seems that the posix_listdir() function assumes that NULL can only mean end-of-file. Therefore, in the situation where readdir() returns NULL due to some error, such as an I/O Error, posix_listdir() ends the while loop started at line 1665 and goes to the closedir() call at line 1702. This results in an os.listdir() call returning an empty list (as if the directory had no contents) instead of raising an exception. This error was noticed because we performed an ls in a particular directory and it returned with an I/O error. I was then writing a python script to monitor for this condition when I found that the os.listdir() in this directory returned an empty list instead of an I/O error. This behavior was noticed using Python 2.3.4; I looked at the latest (as of 2006-04-07) stable release source (Python 2.4.3) to investigate and to provide the details in this bug report. I also took a quick look at the most recent 2.5.x code and although the posix_listdir function has changed, it still appears as if it would return an empty list if the readdir() call returns NULL. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-11 06:51 Message: Logged In: YES user_id=849994 Thank you for the report, fixed in rev. 45259, 45260. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467952&group_id=5470 From noreply at sourceforge.net Tue Apr 11 09:21:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 00:21:09 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by hvb_tup You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this 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 Submitted By: cheops (atila-cheops) Assigned to: Peter ? strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-04-11 07:21 Message: Logged In: YES user_id=1434251 I looked at the patch #1467770 you mentioned and downloaded the patch. Is it correct that _deadlock variable is used in the definition of poll but it is not in the argument list? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:57 Message: Logged In: YES user_id=1276121 see patch #1467770 ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:50 Message: Logged In: YES user_id=1488657 > Simply list operations such as remove() and append() are > thread safe, OK, my apologies... I did not know. I did some more tests. On Linux, I found lots of: File "./subprocess.py", line 428, in call return Popen(*args, **kwargs).wait() File "./subprocess.py", line 1023, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes The try...except solution does not handle this (since we are in the "posix" section). In my opinion, the call to _cleanup() in Popen.__init__() is useless (it just checks if older processes have stopped when a new one is started. I cannot see why it could be mandatory) and it is the root of this bug. I commented it out (line 506) and retried my tests on Linux & Windows plateforms: I had no exception at all. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2006-03-29 05:11 Message: Logged In: YES user_id=344921 >I think accesses to _active should be serialized in a >thread-safe way. _active could be a Queue (from the Queue >module) for example Simply list operations such as remove() and append() are thread safe, so there should be no need for a Queue. Also, a Queue cannot be used since the subprocess module needs to be compatible with Python 2.2. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-28 23:17 Message: Logged In: YES user_id=1488657 I am running into the same problem on a Windows 2k/XP plateform with a multi-threaded application. It occurs randomly. It has never appened (yet) on a Linux plateform. I think accesses to _active should be serialized in a thread-safe way. _active could be a Queue (from the Queue module) for example. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-25 08:10 Message: Logged In: YES user_id=1434251 Wouldn't it be best to completely remove any references to "_active" and "_cleanup"? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-01-25 07:08 Message: Logged In: YES user_id=1276121 As suggested by astrand adding a try ... except clause in the file subprocess.py did the job I had to add that try ... except clause in 2 places if you look in the file there are 2 instances were list.remove(x) occurs unprotected. try: list.remove(x) except: pass I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three needed the patch. Hope this helps. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Tue Apr 11 10:18:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 01:18:20 -0700 Subject: [ python-Bugs-1468231 ] test_grp test_pwd fail on Linux Message-ID: Bugs item #1468231, was opened at 2006-04-11 08:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468231&group_id=5470 Please note that this 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 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp test_pwd fail on Linux Initial Comment: Python 2.5a1, SUSE Linux test_grp test_pwd fails when running "make test" ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 10:18 Message: Logged In: YES user_id=21627 This is a duplicate of #1465646. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468231&group_id=5470 From noreply at sourceforge.net Tue Apr 11 10:45:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 01:45:05 -0700 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 10:08 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this 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: AST Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-04-11 08:45 Message: Logged In: YES user_id=4771 Another one: the literal -2147483648 (i.e. the value of -sys.maxint-1) gives a long in 2.5, but an int in <= 2.4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 07:30 Message: Logged In: YES user_id=33168 The tuple store problem is fixed. The only outstanding item is the LOAD_CONST/POP_TOP. I will fix that soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-18 06:56 Message: Logged In: YES user_id=33168 Jeremy, there's no need to read anything before my last comment at 2005-12-17 23:10. The last two by Armin, Michael, then my last comment are the only important ones. Everything that occurred before my 2005-12-17 comment was taken care of AFAIK. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-02-12 21:54 Message: Logged In: YES user_id=4771 Subscripting is generally a bit sloppy: e.g. the AST model has no way to distinguish between a single value and a one-element tuple value! See: >>> d = {} >>> d[1,] = 6 >>> d {1: 6} # ! I suggest we fix the model to turn the 'subs' of the 'Subscript' node from a list of nodes to a single, mandatory 'sub' node. If tupling is necessary, it can be explicitly represented with a 'sub' containing a 'Tuple' node. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-09 15:02 Message: Logged In: YES user_id=6656 We found another one. Something is wrong in the compilation of augmented assignment to subscriptions containing tuples; running this code: class C: def __setitem__(self, i, v): print i, v def __getitem__(self, i): print i return 0 c = C() c[4,5] += 1 gives a spurious exception: Traceback (most recent call last): File "", line 1, in TypeError: object does not support item assignment By contrast, "c[(4,5)] += 1" works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 07:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-11 00:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 23:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 10:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 19:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-23 04:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 07:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 10:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 10:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Tue Apr 11 11:26:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 02:26:48 -0700 Subject: [ python-Bugs-1465408 ] HP-UX11i installation failure Message-ID: Bugs item #1465408, was opened at 2006-04-06 01:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 Please note that this 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 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i installation failure Initial Comment: % uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license % cc -V cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006] env CC=cc CXX=aCC ./configure --prefix=/var/tmp/rwgk/py25a1 --without-gcc make The output of make ends with: No such file or directory: python *** Error exit code 127 Stop. I'll upload the full output of configure and make. Note that the testdrive machine is publically accessible: http://www.testdrive.hp.com/ telnet td176.testdrive.hp.com ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 11:26 Message: Logged In: YES user_id=21627 The welease script should check that the exported time stamps are already in the right sequence (i.e. Python-ast.[ch] newer than their dependencies). If this is not the case, a commit should be forced on the file that is too old. Then, if the files don't change before the next release, no time stamp changing will be necessary. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-06 18:16 Message: Logged In: YES user_id=71407 I get a complete build if I touch Include/Python-ast.h Python/Python-ast.c before running configure. If you wait a second after the svn export and then touch these two files I'd expect the tarball to work out of the box. Another idea is to work with MD5 signatures, like SCons does. But if you don't have a Python yet it is probably difficult to find a fully portable solution. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 09:56 Message: Logged In: YES user_id=29957 Right. Python.asdl and the output files that depend on it have the same timestamps in the tarball. This is because they get updated and all checked in in the same svn revision. When the export is done, the timestamps are set to the same time. Possible solutions: - make ignores this failure. Bad, because it might stop _real_ errors. - make catches lack of Python, and skips the step. Ugly, and hard to do in a platform-compatible way. - I change the 'welease.py' script to adjust the timestamps of the files before making the release tarballs. This is so nasty it makes me sick. But I can't see a better option. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-06 09:48 Message: Logged In: YES user_id=29957 If you put a '-' at the start of the line in the Makefile, it should build ok. Make it: $(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES) -$(ASDLGEN) $(AST_ASDL) Obviously there's some issues with timestamps on the files and it's trying to rebuild the file unnecessarily... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&group_id=5470 From noreply at sourceforge.net Tue Apr 11 11:41:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 02:41:40 -0700 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 11:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this 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: AST Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-04-11 10:41 Message: Logged In: YES user_id=6656 Good morning Armin! I've reported that bug already: http://python.org/sf/1441486 There's a patch which purports to fix it: http://python.org/sf/1446922 but I haven't gotten around to testing it. (this is running the pypy/module/array tests or something, isn't it?) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-11 09:45 Message: Logged In: YES user_id=4771 Another one: the literal -2147483648 (i.e. the value of -sys.maxint-1) gives a long in 2.5, but an int in <= 2.4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 08:30 Message: Logged In: YES user_id=33168 The tuple store problem is fixed. The only outstanding item is the LOAD_CONST/POP_TOP. I will fix that soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-18 06:56 Message: Logged In: YES user_id=33168 Jeremy, there's no need to read anything before my last comment at 2005-12-17 23:10. The last two by Armin, Michael, then my last comment are the only important ones. Everything that occurred before my 2005-12-17 comment was taken care of AFAIK. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-02-12 21:54 Message: Logged In: YES user_id=4771 Subscripting is generally a bit sloppy: e.g. the AST model has no way to distinguish between a single value and a one-element tuple value! See: >>> d = {} >>> d[1,] = 6 >>> d {1: 6} # ! I suggest we fix the model to turn the 'subs' of the 'Subscript' node from a list of nodes to a single, mandatory 'sub' node. If tupling is necessary, it can be explicitly represented with a 'sub' containing a 'Tuple' node. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-09 15:02 Message: Logged In: YES user_id=6656 We found another one. Something is wrong in the compilation of augmented assignment to subscriptions containing tuples; running this code: class C: def __setitem__(self, i, v): print i, v def __getitem__(self, i): print i return 0 c = C() c[4,5] += 1 gives a spurious exception: Traceback (most recent call last): File "", line 1, in TypeError: object does not support item assignment By contrast, "c[(4,5)] += 1" works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 07:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-11 00:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 23:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 10:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 20:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-23 05:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 08:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 13:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Tue Apr 11 13:13:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 04:13:17 -0700 Subject: [ python-Bugs-1464444 ] ctypes should be able to link with installed libffi Message-ID: Bugs item #1464444, was opened at 2006-04-04 21:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 Please note that this 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 13:13 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r45278. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-10 22:45 Message: Logged In: YES user_id=60903 documentation added. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 14:00 Message: Logged In: YES user_id=21627 The code is fine, but it lacks documentation. There should be some way to learn about --with-system-ffi, preferably by either reading ./configure --help output, or reading README. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library buildable on hppa (or maybe this is just the failed (it's really a 32bit runtime, but hppa64-linux is detected). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 14:34 Message: Logged In: YES user_id=11105 I tend to accept this patch. Martin, any objections? Matthias: do any of the buildbot slaves have a system libffi installed? About the code: And, shouldn't it be enough to let the compiler find ffi.h? I assume that the presence of this file should indicate that libffi.so is installed - why do we have to scan this file for '#define LIBFFI_H', and why do we have to search for the ffi shared library? Would updating the included libffi code to GCC HEAD bring any advantages? The currently included code has been patched in a few places, to avoid some of the compiler warnings, and to allow compilation on OS X 10.3 (which does not know the 'live_support' segment attribute, see Python bug 1460514). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464444&group_id=5470 From noreply at sourceforge.net Tue Apr 11 13:21:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 04:21:41 -0700 Subject: [ python-Bugs-1466301 ] ImportError: Module _subprocess not found Message-ID: Bugs item #1466301, was opened at 2006-04-07 14:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 Please note that this 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: 3rd Party Status: Open >Resolution: Invalid Priority: 5 Submitted By: Africanis (africanis) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: Module _subprocess not found Initial Comment: I'm using Enthought Python 2.3.5 together with IPython and matplotlib on Windows XP SP2. I had problems importing pylab (in order actually to use matplotlib) until I changed the attached file (see from line 365). I have absolutely no idea what effect this will have on other modules (I'm fairly new to programming), but matplotlib seems to work okay now. Ignorance is bliss... ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 13:21 Message: Logged In: YES user_id=21627 Thanks for the patch. I'm not quite sure what you have been doing: Python 2.3.5 did not include the subprocess module at all. So if you got it either from IPython or from Enthought Python, you could report the problem to them. They should either include _subprocess.pyd (as it was released with Python 2.4), or enable the if 0 block, meant for pywin32, or drop subprocess entirely. In any case, this should be a problem for Python 2.4 or (the upcoming) Python 2.5. Closing it as a third-party bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 From noreply at sourceforge.net Tue Apr 11 19:19:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 10:19:16 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Tue Apr 11 20:00:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 11:00:24 -0700 Subject: [ python-Bugs-1468727 ] Possible Integer overflow Message-ID: Bugs item #1468727, was opened at 2006-04-11 18:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470 Please note that this 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 Submitted By: ekellinis (ekellinis) Assigned to: Nobody/Anonymous (nobody) Summary: Possible Integer overflow Initial Comment: There is possible integer overlow in the fcntlmodule.c ================================= fcntl_fcntl(PyObject *self, PyObject *args) { int fd; int code; int arg; int ret; char *str; Py_ssize_t len; char buf[1024]; if (PyArg_ParseTuple(args, "O&is#:fcntl", conv_descriptor, &fd, &code, &str, &len)) { if (len > sizeof buf) { PyErr_SetString(PyExc_ValueError, "fcntl string arg too long"); return NULL; } memcpy(buf, str, len); ================================= Explanation : if "len" receives very large value (>integer) there is a possiblity that it will become negative and the value will bypass the if statement and go directly to memcpy(buf, str, len); The latest revision of the module (42787) has int replaced with Py_ssize_t which as it mentions at http://www.python.org/dev/peps/pep-0353/ "...Py_ssize_t is introduced, which has the same size as the compiler's size_t type, but is signed.." so the problem seem to still be there. -The int type is used from revision 42093 and back Someone needs to be able to execute arbitrary python to exploit it , possible effect : break from the Python sandbox ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470 From noreply at sourceforge.net Tue Apr 11 20:01:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 11:01:23 -0700 Subject: [ python-Bugs-1468727 ] Possible Integer overflow Message-ID: Bugs item #1468727, was opened at 2006-04-11 18:00 Message generated for change (Settings changed) made by ekellinis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470 Please note that this 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: 7 Submitted By: ekellinis (ekellinis) Assigned to: Nobody/Anonymous (nobody) Summary: Possible Integer overflow Initial Comment: There is possible integer overlow in the fcntlmodule.c ================================= fcntl_fcntl(PyObject *self, PyObject *args) { int fd; int code; int arg; int ret; char *str; Py_ssize_t len; char buf[1024]; if (PyArg_ParseTuple(args, "O&is#:fcntl", conv_descriptor, &fd, &code, &str, &len)) { if (len > sizeof buf) { PyErr_SetString(PyExc_ValueError, "fcntl string arg too long"); return NULL; } memcpy(buf, str, len); ================================= Explanation : if "len" receives very large value (>integer) there is a possiblity that it will become negative and the value will bypass the if statement and go directly to memcpy(buf, str, len); The latest revision of the module (42787) has int replaced with Py_ssize_t which as it mentions at http://www.python.org/dev/peps/pep-0353/ "...Py_ssize_t is introduced, which has the same size as the compiler's size_t type, but is signed.." so the problem seem to still be there. -The int type is used from revision 42093 and back Someone needs to be able to execute arbitrary python to exploit it , possible effect : break from the Python sandbox ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470 From noreply at sourceforge.net Tue Apr 11 22:10:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 13:10:54 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this 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 Submitted By: cheops (atila-cheops) Assigned to: Peter ? strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- >Comment By: cheops (atila-cheops) Date: 2006-04-11 20:10 Message: Logged In: YES user_id=1276121 there are 2 definitions of the function poll, one for windows and one for POSIX systems in the windows version _deadlock is not used in the POSIX version _deadlock is used see also modification made by loewis in committed version 45234 ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-04-11 07:21 Message: Logged In: YES user_id=1434251 I looked at the patch #1467770 you mentioned and downloaded the patch. Is it correct that _deadlock variable is used in the definition of poll but it is not in the argument list? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:57 Message: Logged In: YES user_id=1276121 see patch #1467770 ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:50 Message: Logged In: YES user_id=1488657 > Simply list operations such as remove() and append() are > thread safe, OK, my apologies... I did not know. I did some more tests. On Linux, I found lots of: File "./subprocess.py", line 428, in call return Popen(*args, **kwargs).wait() File "./subprocess.py", line 1023, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes The try...except solution does not handle this (since we are in the "posix" section). In my opinion, the call to _cleanup() in Popen.__init__() is useless (it just checks if older processes have stopped when a new one is started. I cannot see why it could be mandatory) and it is the root of this bug. I commented it out (line 506) and retried my tests on Linux & Windows plateforms: I had no exception at all. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2006-03-29 05:11 Message: Logged In: YES user_id=344921 >I think accesses to _active should be serialized in a >thread-safe way. _active could be a Queue (from the Queue >module) for example Simply list operations such as remove() and append() are thread safe, so there should be no need for a Queue. Also, a Queue cannot be used since the subprocess module needs to be compatible with Python 2.2. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-28 23:17 Message: Logged In: YES user_id=1488657 I am running into the same problem on a Windows 2k/XP plateform with a multi-threaded application. It occurs randomly. It has never appened (yet) on a Linux plateform. I think accesses to _active should be serialized in a thread-safe way. _active could be a Queue (from the Queue module) for example. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-25 08:10 Message: Logged In: YES user_id=1434251 Wouldn't it be best to completely remove any references to "_active" and "_cleanup"? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-01-25 07:08 Message: Logged In: YES user_id=1276121 As suggested by astrand adding a try ... except clause in the file subprocess.py did the job I had to add that try ... except clause in 2 places if you look in the file there are 2 instances were list.remove(x) occurs unprotected. try: list.remove(x) except: pass I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three needed the patch. Hope this helps. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Tue Apr 11 23:45:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 14:45:50 -0700 Subject: [ python-Bugs-1463840 ] logging.StreamHandler ignores argument if it compares False Message-ID: Bugs item #1463840, was opened at 2006-04-03 21:37 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 Please note that this 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 Submitted By: Paul Winkler (slinkp) Assigned to: Vinay Sajip (vsajip) Summary: logging.StreamHandler ignores argument if it compares False Initial Comment: The docs at http://docs.python.org/lib/node346.html say this: """ class StreamHandler( [strm]) Returns a new instance of the StreamHandler class. If strm is specified, the instance will use it for logging output; otherwise, sys.stderr will be used. """ However, that's not quite true. StreamHandler.__init__() actually tests for truth of strm, which means you have to be careful that strm does not happen to evaluate to boolean false. My use case: I'm writing some tests that verify that certain methods put certain strings into the logs. So my setUp() adds a StreamHandler with its stream set to an instance of this trivial class: class FakeLog(list): def write(self, msg): self.append(msg) def flush(self): pass ... which does not work, because an empty list evaluates to false, so my handler writes to stderr even though i told it not to. It's trivial to work around this by adding a __nonzero__ method, but the need to do so is certainly not clear from the docs. Therefore imho this is a bug. The patch is trivial, and is attached. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-04-11 21:45 Message: Logged In: YES user_id=308438 Fix checked into Subversion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 06:20 Message: Logged In: YES user_id=33168 Vinay, any comments? We are preparing for 2.5 alpha1 within a day. There will be freeze real soon now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 From noreply at sourceforge.net Wed Apr 12 02:08:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Apr 2006 17:08:49 -0700 Subject: [ python-Bugs-1466641 ] Bogus SyntaxError in listcomp Message-ID: Bugs item #1466641, was opened at 2006-04-08 00:51 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Wouters (twouters) Summary: Bogus SyntaxError in listcomp Initial Comment: The attached syn.py gives a SyntaxError in 2.5a1 and trunk. Works fine in earlier Pythons. Whittled down from real-life Zope3 source. def d(dir): return [fn for fn in os.listdir(dir) if fn if fn] ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-12 02:08 Message: Logged In: YES user_id=34209 Fixed in trunk, revision 45286. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-04-10 02:43 Message: Logged In: YES user_id=34209 Yeah, this is definately caused by the PEP 308 patch, so I guess the error is mine (but don't tell anyone.) Unless someone beats me to it, I'll fix it and add a test tomorrow (but please don't fix it without checking in some tests.) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 16:57 Message: Logged In: YES user_id=849994 Changing list_if: 'if' test [list_iter] to list_if: 'if' old_test [list_iter] solves the problem. Conditionals must then be enclosed in parens. Generator expressions are also affected. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-09 16:50 Message: Logged In: YES user_id=849994 Haha. The second "if" is seen as the beginning of a conditional expression, so return [fn for fn in os.listdir(dir) if fn if fn else fn] works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-09 06:07 Message: Logged In: YES user_id=31435 The whittled-down version looks ridiculous, but the original wasn't quite such an affront to beauty :-) It's really no stranger than allowing pure "if" statements to nest, and it would be more painful to contort the grammar to disallow it (I haven't looked at the 2.5 parser, but it was very surprising to me that it didn't allow it!). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-04-09 05:32 Message: Logged In: YES user_id=1038590 Is including two if clauses with a single for clause really meant to be legal? *goes and looks at language reference* Wow. What a strange way to write "and". . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:01:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:01:05 -0700 Subject: [ python-Bugs-416288 ] infrequent memory leak in pyexpat Message-ID: Bugs item #416288, was opened at 2001-04-15 19:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 2 Submitted By: douglas orr (dougbo) >Assigned to: Nobody/Anonymous (nobody) Summary: infrequent memory leak in pyexpat Initial Comment: In pyexpat.c, the macro call for the handler dispatch (my##NAME##Handler) for CharacterHandler allocates an object implicitly by calling one of the conversion-to- unicode routines. If there is a problem in the PyBuildValue, resulting in args == NULL, that object will be leaked. Low priority, but the macros probably need some reworking to handle this. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-03-29 00:20 Message: Logged In: YES user_id=21627 No, currently, it can only leak: the argument being passed will have an extra ref count, which supposedly will be consumed by the tuple. If something fails, some of the N arguments will have been stored in the tuple-under-construction, and will be released when the tuple is released. 'N' arguments not yet consumed will leak. Processing should continue in case of an error, and DECREF all N arguments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-28 23:34 Message: Logged In: YES user_id=6380 Hm, the 'N' format code looks really scary. Can't it end up DECREF'ing an object too many times if something fails? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2001-06-09 13:48 Message: Logged In: YES user_id=21627 That seems to be a bug in Py_BuildValue: It should decref its N arguments if it can't create a tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:01:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:01:45 -0700 Subject: [ python-Bugs-451607 ] SSL support in socket module needs tests Message-ID: Bugs item #451607, was opened at 2001-08-16 18:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 Please note that this 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 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-10-10 10:51 Message: Logged In: YES user_id=21627 I don't think this is relevant here: OpenSSL uses whatever device it uses; we need not to concern ourselves with OpenSSL's choice. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 10:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-10-10 10:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 20:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2001-10-11 21:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 20:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2001-10-11 20:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2001-09-03 17:12 Message: Logged In: YES user_id=21627 I'd suggest an approach similar to the one in test_socket, i.e. test only if can_fork. As for the certificates: I think they should be generated in advance and included into the test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 15:53 Message: Logged In: YES user_id=12800 There is currently an extremely minimal test in test_socket_ssl.py, but it is fairly bogus because it requires an outside network connection. The only test there just tries to hit https://sf.net. Ideally, there would be a set of regression tests that only required local resources. I.e. it would set up a local SSL server, then do connects to it to test the various SSL features in socket module. Take a look at test_socket_ssl.py in the 2.2 cvs and see if you can improve matters. From what I understand, the tricky part is generating all the necessary certificates, etc. Also, if you intend to work on this, please log in to SF to continue this dialog so we know who we're talking to! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-28 07:58 Message: Logged In: NO I may be able to help with this. I'm fairly familiar with SSL in general, though not about the socket module. What's needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:02:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:02:33 -0700 Subject: [ python-Bugs-719888 ] tokenize module w/ coding cookie Message-ID: Bugs item #719888, was opened at 2003-04-11 21:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719888&group_id=5470 Please note that this 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: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: tokenize module w/ coding cookie Initial Comment: The tokenize module should honor the coding cookie in a file, probably so that it returns Unicode strings with decoded characters. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:02 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719888&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:03:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:03:34 -0700 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 12:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) >Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:03 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 14:23 Message: Logged In: YES user_id=33168 I think I remember hearing something about an incompatibility. The two best people to discuss this are probably Martin v. Loewis and Fred Drake. I'm assigning to Martin, perhaps he can shed some more light on the issues. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 13:46 Message: Logged In: YES user_id=200117 I have now installed Python-2.3.3 plus PyXML-0.8.3 and the core dump in 'make test' has returned. So, it looks like a compatability problem with PyXML-0.8.3 ? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 10:25 Message: Logged In: YES user_id=200117 HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license This is the configure command I used: base_inst_dir=/opt python_link=${base_inst_dir}/python CC=cc \ OPT="+O2 -z +Onofltacc +ESlit +Oentrysched \ +Odataprefetch +Onolimit +DA2.0" \ INSTALL="./install-sh -c" \ ./configure --with-threads --without-gcc \ --with-cxx=/opt/aCC/bin/aCC --without-libd \ --with-cycle-gc --prefix=$python_link \ --exec-prefix=$python_link This is exactly the same command I have used on previous Python 2.3 releases which did not core dump in 'make test'. Note it uses the native HP compiler. I have now just rebuilt without optimisation, using: CC=cc \ INSTALL="./install-sh -c" \ ./configure --with-threads --without-gcc \ --with-cxx=/opt/aCC/bin/aCC --without-libd \ --with-cycle-gc --prefix=$python_link \ --exec-prefix=$python_link It still core dumps at the same point in the second pass of 'make test'. I have attached a stack trace from the core file. I noticed that this has references to /opt/python/lib/python2.3/site- packages/_xmlplus/parsers/pyexpat.sl. This is the previous installation of Python 2.3.2 plus PyXML-0.8.3. I wondered if I had forgotten to reset $PYTHONPATH before running 'make test', so I did that and tried again but it still core dumped. So next I reset the symbolic link /opt/python to the empty directory /opt/python-2.3.3 and ran 'make test' again. This time it didn't core dump! So why does the test suite access the previous installation when PYTHONPATH doesn't include it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 04:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:05:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:05:28 -0700 Subject: [ python-Bugs-896330 ] pyconfig.h is not placed in --includedir Message-ID: Bugs item #896330, was opened at 2004-02-13 09:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896330&group_id=5470 Please note that this 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: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: G?ran Uddeborg (goeran) >Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h is not placed in --includedir Initial Comment: When configuring Python with an explicit --includedir most of the header files do turn up in this directory. But the pyconfig.h is still placed in $(prefix)/include. I assume it is a bug, and this file too should be placed according to --includedir. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:05 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Pelle Johansson (morth) Date: 2004-10-23 15:52 Message: Logged In: YES user_id=180081 Actually, pyconfig.h is placed in $(exec-prefix)/include. This is fine as the file is architecture dependant. However the other header files use a local #include "pyconfig.h" which will not match if it's not the same dir. If you like me want a common directory for all archindependant files and then separate for each arch it causes additional headache, since there's no easy way for me to symlink from the arch include/ dir to the archindependant, as they have a common subdir (python2.3/ in my case). Currently it seems I'll have to symlink each header file individually from the archindependent dir to the arch ones. Ideally pyconfig.h would be put directly in $(exec-prefix)/include/ and be refered to as . I could then just symlink the subdir. Whether to honor includedir or not I don't know, I'll leave that problem to the project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896330&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:05:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:05:51 -0700 Subject: [ python-Bugs-969718 ] BASECFLAGS are not passed to module build line Message-ID: Bugs item #969718, was opened at 2004-06-09 17:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jason Beardsley (vaxhacker) >Assigned to: Nobody/Anonymous (nobody) Summary: BASECFLAGS are not passed to module build line Initial Comment: The value of BASECFLAGS from /prefix/lib/pythonver/config/Makefile is not present on the compile command for modules being built by distutils ("python setup.py build"). It seems that only the value of OPT is passed along. This is insufficient when BASECFLAGS contains "-fno-static-aliasing", since recent versions of gcc will emit incorrect (crashing) code if this flag is not provided, when compiling certain modules (the mx products from egenix, for example). I did try to set CFLAGS in my environment, as directed by documentation, but this also had zero effect on the final build command. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:05 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: nyogtha (nyogtha) Date: 2006-01-13 22:19 Message: Logged In: YES user_id=1426882 This is still a bug in Python 2.4.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:06:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:06:17 -0700 Subject: [ python-Bugs-995956 ] TclError with intel's hypertheading Message-ID: Bugs item #995956, was opened at 2004-07-22 16:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Tobias Haar (thaar) >Assigned to: Nobody/Anonymous (nobody) Summary: TclError with intel's hypertheading Initial Comment: If i use the "intel hyperthreading technologie", my python application make a coredump with the output: File "C:\PROGRA~2\PYTHON~2\lib\lib-tk\Tkinter.py", line 472, in after return self.tk.call('after', ms, name) TclError: expected integer but got "9118984callit" The test runs at the following system. Microsoft windows 2000 5.00.2195 Service Pack 4 Intel Pentium 4 CPU 2.5 Ghz 522.988 KB RAM. The error never occur, if i turn the hyperthreading in the bios off. I made the self test at 2 other pc with the same hardware and configurations. The result was the same. I made another test with a linux pc, a laptop with xp and a laptop with win2000. All without hyperthreading. The error has not occured. I add the log file and the test as attachment. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-07-30 01:38 Message: Logged In: YES user_id=593130 I believe TclError means that the error came from the embedded Tcl interpreter. If so, and if the Pytyhon call ultimately feeds appropriate data to Tcl, the problem comes not from Python but one of Tcl, Win2000, or the chip, or the relationship between them. If you are running current Python with current Tcl, the best we could do is add a warning to turn off Hyperthreading if strange errors occur, but I am not sure where. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:06:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:06:34 -0700 Subject: [ python-Bugs-1076515 ] shutil.move clobbers read-only files. Message-ID: Bugs item #1076515, was opened at 2004-12-01 06:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 Please note that this 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 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move clobbers read-only files. Initial Comment: The summary states it fine. shutil.move happily overwrites read- only files. It looks like it indiscriminately catches OSError, and never bothers to check whether it's a permission error. It'd be nice if permission errors raised an exception that was a subclass of OSError, then it'd be cake to fix this (at least for *nices; I'm not sure about the Windows implications). According to tracker #810879, clobbering read-only files isn't the desired behavior for shutil.copyfile, so I doubt it's desired for shutil.move. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 23:21 Message: Logged In: YES user_id=469548 Your analysis is not correct. On Unix, you need write permission to the *directory* to rename. So the os.rename() call simply succeeds on a read-only file if you have write access to its parent directory. I think we could shield from this by always using the fallback implementation (copy2+unlink(src)), but I'm not sure what the implications of that would be (qua performance and cross-platform issues). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:06:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:06:56 -0700 Subject: [ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed Message-ID: Bugs item #1248997, was opened at 2005-07-31 23:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurie Harper (zodiac) >Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-04 07:30 Message: Logged In: YES user_id=21627 Sounds good. Can you provide a patch? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-08-04 00:14 Message: Logged In: YES user_id=2772 I'd rather see the build-requires line of the spec file have the required -devel packages listed, than fix the spec file to detect whether they're available and possibly build a python with reduced capabilities. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 From noreply at sourceforge.net Wed Apr 12 10:08:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 01:08:19 -0700 Subject: [ python-Bugs-1468727 ] Possible Integer overflow Message-ID: Bugs item #1468727, was opened at 2006-04-11 19:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470 Please note that this 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: Invalid Priority: 7 Submitted By: ekellinis (ekellinis) >Assigned to: Michael Hudson (mwh) Summary: Possible Integer overflow Initial Comment: There is possible integer overlow in the fcntlmodule.c ================================= fcntl_fcntl(PyObject *self, PyObject *args) { int fd; int code; int arg; int ret; char *str; Py_ssize_t len; char buf[1024]; if (PyArg_ParseTuple(args, "O&is#:fcntl", conv_descriptor, &fd, &code, &str, &len)) { if (len > sizeof buf) { PyErr_SetString(PyExc_ValueError, "fcntl string arg too long"); return NULL; } memcpy(buf, str, len); ================================= Explanation : if "len" receives very large value (>integer) there is a possiblity that it will become negative and the value will bypass the if statement and go directly to memcpy(buf, str, len); The latest revision of the module (42787) has int replaced with Py_ssize_t which as it mentions at http://www.python.org/dev/peps/pep-0353/ "...Py_ssize_t is introduced, which has the same size as the compiler's size_t type, but is signed.." so the problem seem to still be there. -The int type is used from revision 42093 and back Someone needs to be able to execute arbitrary python to exploit it , possible effect : break from the Python sandbox ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-04-12 09:08 Message: Logged In: YES user_id=6656 >From a little source staring, I am pretty sure that len can in fact never be negative. If you have exploit code, please share in. On the optimistic premise that I'm not blind, closing this bug. Also, you're letting code execute ioctl and are worried about what else it might be doing ... ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470 From noreply at sourceforge.net Wed Apr 12 12:14:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 03:14:27 -0700 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: Matt Fleming (splitscreen) Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-04-12 10:14 Message: Logged In: YES user_id=1126061 Yeah, your patch looks much better. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 08:15 Message: Logged In: YES user_id=849994 splitscreen: your patch was incomplete and could have overwritten memory. tim_one: Attaching new patch implementing what I proposed in my comment below. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 21:59 Message: Logged In: YES user_id=1126061 Ok, uploading latest patch, not quite sure I've hit the mark here. Please review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 20:43 Message: Logged In: YES user_id=849994 Yes, I want to remove 'U' from the mode since it's at this point already recognized by Python, and it's not meaningful to the underlying C library. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 19:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Wed Apr 12 12:23:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 03:23:15 -0700 Subject: [ python-Bugs-1469163 ] SimpleXMLRPCServer doesn't work anymore on Windows Message-ID: Bugs item #1469163, was opened at 2006-04-12 12:23 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=1469163&group_id=5470 Please note that this 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 Submitted By: kadeko (kadeko) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer doesn't work anymore on Windows Initial Comment: The bug resolution of [ 1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC break the compatibility with Windows system. The new "import fcntl" is not possible on non POSIX system. C:\Python25>C:\Python25\python.exe C:\Python25\server2.py Traceback (most recent call last): File "C:\Python25\server2.py", line 1, in from DocXMLRPCServer import DocXMLRPCServer File "C:\Python25\lib\DocXMLRPCServer.py", line 18, in from SimpleXMLRPCServer import (SimpleXMLRPCServer, File "C:\Python25\lib\SimpleXMLRPCServer.py", line 107, in import os, fcntl ImportError: No module named fcntl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 From noreply at sourceforge.net Wed Apr 12 12:24:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 03:24:27 -0700 Subject: [ python-Bugs-1469163 ] SimpleXMLRPCServer doesn't work anymore on Windows Message-ID: Bugs item #1469163, was opened at 2006-04-12 12:23 Message generated for change (Settings changed) made by kadeko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 Please note that this 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: 7 Submitted By: kadeko (kadeko) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer doesn't work anymore on Windows Initial Comment: The bug resolution of [ 1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC break the compatibility with Windows system. The new "import fcntl" is not possible on non POSIX system. C:\Python25>C:\Python25\python.exe C:\Python25\server2.py Traceback (most recent call last): File "C:\Python25\server2.py", line 1, in from DocXMLRPCServer import DocXMLRPCServer File "C:\Python25\lib\DocXMLRPCServer.py", line 18, in from SimpleXMLRPCServer import (SimpleXMLRPCServer, File "C:\Python25\lib\SimpleXMLRPCServer.py", line 107, in import os, fcntl ImportError: No module named fcntl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 From noreply at sourceforge.net Wed Apr 12 14:08:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 05:08:47 -0700 Subject: [ python-Bugs-1469163 ] SimpleXMLRPCServer doesn't work anymore on Windows Message-ID: Bugs item #1469163, was opened at 2006-04-12 20:23 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 Please note that this 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: 7 Submitted By: kadeko (kadeko) >Assigned to: Anthony Baxter (anthonybaxter) Summary: SimpleXMLRPCServer doesn't work anymore on Windows Initial Comment: The bug resolution of [ 1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC break the compatibility with Windows system. The new "import fcntl" is not possible on non POSIX system. C:\Python25>C:\Python25\python.exe C:\Python25\server2.py Traceback (most recent call last): File "C:\Python25\server2.py", line 1, in from DocXMLRPCServer import DocXMLRPCServer File "C:\Python25\lib\DocXMLRPCServer.py", line 18, in from SimpleXMLRPCServer import (SimpleXMLRPCServer, File "C:\Python25\lib\SimpleXMLRPCServer.py", line 107, in import os, fcntl ImportError: No module named fcntl ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-12 22:08 Message: Logged In: YES user_id=29957 Fixed in r45305 by handling the 'no fcntl module available' case. Thanks for the bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 From noreply at sourceforge.net Wed Apr 12 16:39:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 07:39:15 -0700 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 11:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 14:39 Message: Logged In: YES user_id=849994 As 2.3.x is not maintained anymore, should this be closed? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 08:03 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 13:23 Message: Logged In: YES user_id=33168 I think I remember hearing something about an incompatibility. The two best people to discuss this are probably Martin v. Loewis and Fred Drake. I'm assigning to Martin, perhaps he can shed some more light on the issues. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 12:46 Message: Logged In: YES user_id=200117 I have now installed Python-2.3.3 plus PyXML-0.8.3 and the core dump in 'make test' has returned. So, it looks like a compatability problem with PyXML-0.8.3 ? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 09:25 Message: Logged In: YES user_id=200117 HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license This is the configure command I used: base_inst_dir=/opt python_link=${base_inst_dir}/python CC=cc \ OPT="+O2 -z +Onofltacc +ESlit +Oentrysched \ +Odataprefetch +Onolimit +DA2.0" \ INSTALL="./install-sh -c" \ ./configure --with-threads --without-gcc \ --with-cxx=/opt/aCC/bin/aCC --without-libd \ --with-cycle-gc --prefix=$python_link \ --exec-prefix=$python_link This is exactly the same command I have used on previous Python 2.3 releases which did not core dump in 'make test'. Note it uses the native HP compiler. I have now just rebuilt without optimisation, using: CC=cc \ INSTALL="./install-sh -c" \ ./configure --with-threads --without-gcc \ --with-cxx=/opt/aCC/bin/aCC --without-libd \ --with-cycle-gc --prefix=$python_link \ --exec-prefix=$python_link It still core dumps at the same point in the second pass of 'make test'. I have attached a stack trace from the core file. I noticed that this has references to /opt/python/lib/python2.3/site- packages/_xmlplus/parsers/pyexpat.sl. This is the previous installation of Python 2.3.2 plus PyXML-0.8.3. I wondered if I had forgotten to reset $PYTHONPATH before running 'make test', so I did that and tried again but it still core dumped. So next I reset the symbolic link /opt/python to the empty directory /opt/python-2.3.3 and ran 'make test' again. This time it didn't core dump! So why does the test suite access the previous installation when PYTHONPATH doesn't include it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 03:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Apr 12 16:52:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 07:52:45 -0700 Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix Message-ID: Bugs item #1433877, was opened at 2006-02-17 23:29 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 6 Submitted By: Quentin Barnes (qbarnes) >Assigned to: Michael Hudson (mwh) Summary: string parameter to ioctl not null terminated, includes fix Initial Comment: I ran across this problem in Python 2.3.3 and see it is still there in 2.4.2. When running the test_pty.py test case, I would get intermittant failures depending on how the test was invoked or the compiler flags used on Solaris. Trussing the interpreter while running the test revealed: ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL There was garbage on the end of the string when it would fail. I tracked the problem back to fcntl_ioctl() in fcntlmodule.c. The string was not being NULL terminated, but relied on having zeroed gargage on the stack to work. I checked the source for 2.4.2 and noticed the same problem. Patch to fix the problem is attached. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-12 16:52 Message: Logged In: YES user_id=34209 Hrm. After giving this some thought, perhaps we should do memcpy(buf, str, len+1) instead of memcpy(buf, str, len) buf[len] = '\0' (And do this in the writable-buffer case as well, when we use memcpy.) Other than that, I think this is the right fix. Assigning to mwh for second (third? fourth?) opinion. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:22 Message: Logged In: YES user_id=34209 Huh, I never even saw this patch, in spite of the high priority and it being assigned to me. We didn't discuss it at PyCon (at least, I wasn't party to the discussion) but I guess this patch doesn't really hurt, and does fix actual problems. I'm wary of fudging fcntl/ioctl too much; I'd _much_ rather try and come up with a decent interface for Py3k, with mutable bytestrings and all that, maybe some nice automatic argument-type-conversion or higher-level interface for common features (like advisory locks) -- and only keep 2.x's fcntl working as well as it does. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 21:52 Message: Logged In: YES user_id=6380 mwh: Sorry about the docstring gripe -- I read the fcntl() docstring which is right above the ioctl() implementation and never realized that this particular C module places the doc strings *after* the functions. (I think that's bad style but there it is.) I think the priority was set to 9 by Neal to get Thomas' attention. gbarnes: We'll decide this one at PyCon. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-20 19:00 Message: Logged In: YES user_id=288734 I didn't write new code that causes this problem by calling ioctl with a string that needed to be null terminated. It was already in Python code itself. See Lib/pty.py for the code. I reworked the patch as discussed below and retested it. All built-in tests passed. I've attached it. I hae no idea of Python coding conventions or style. Hopefully I didn't violate them too badly. (This was weird. SF rejected the text above when I submitted it, but it took the patch file. The patch file shows up as "nobody". Resubmitting this text.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-20 11:54 Message: Logged In: YES user_id=6656 Seeing as some of this is my code... Guido, the ioctl docstring *does* mention mutate_arg. I agree that the documentation should have been updated for 2.4 and 2.5... and the situation is a mess, yes, but one that I couldn't see a better way around when the feature was added (it was much discussed in the bug report at the time). It certainly never occurred to me that you might need/want to pass a NULL terminated string to ioctl. I don't think this is a priority 9 report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 06:04 Message: Logged In: YES user_id=6380 Sorry for the confusion. I was in part responding to an off-line discussion I had with Neal Norwitz, to which you weren't a party. You can ignore my comments about safety and crashing. The difference in marshalling Python data to C data for ioctl(), compared to the many other places where (indeed) this problem has been solved before, is that almost everywhere else, we *know* what the data is supposed to mean. C has many more data types than Python, and the choice of how to convert a string, or an int, to C data depends on what is expected by the receiver of the C data. Unfortunately for ioctl we don't know the required C data type because it's defined by the kernel module that handles the particular ioctl opcode. Some of these (like the one you apparently ran into when porting the pty code to Solaris) require a null-terminated string; others (like the classic tty ioctls) require a C structure, which in Python can be created by using the struct module. Both return Python strings. I tend to agree with your conclusion that we should extend the buffer to 1025 bytes and not bother null-terminating non-string data. Would you like to attempt another patch? ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-20 01:31 Message: Logged In: YES user_id=288734 I've practically never used python. I just found this bug in the interpreter while porting the tool to the current Solaris compiler release, so please keep that in mind about my lack of python knowledge. I also have no idea who's who as well in the python world so forgive me if I've stepped on anyone's toes. I don't follow the remark about "making ioctl 'safe'". I never said anything about making it "safe". It's about a bug. I also never said anything about the interpreter crashing. The interpreter never crashed. The pty test just simply failed since the module name passed to the OS's ioctl was corrupted. Are you sure you responded to the right bug report with these remarks? Anyways... This problem should be reduced to a classic data marshaling problem between python data space and C data space which should have already been addressed in many contexts many times before in the interpreter. How are python strings converted for use by C in similar situations? This problem I encountered is either a bug in the code that passed the string to the ioctl service by not putting an explicit '\0' on the end of the "ptem" string, or it is a bug in the fcntlmodule.c which should have done it for it. Which is it? If a python code isn't expected to put a literal null at the end of their string when passing to a C service, then ioctl needs to be fixed similar to the way in my patch. As for null-terminating other raw data, I don't see the point other than a defensive programming practice. The problem I ran across is limited to just a data marshaling problem. The patch only touched the case when the type of data passed to ioctl is known to be a string. As for the buffer vs. documentation, the buffer could be changed to 1025 for the string case, or the documentation could be updated to clarify that, unlike raw data, strings are limited to 1023 to leave room for the requisite null that conversion to a C string requires. I don't think anyone would care either way as long as it is qualified. Since python strings serve dual roles of being both raw data and being just textual containers, one can't assume that a string passed to ioctl is always meant to be just a textual string. Going the 1025 route is probably a 'better' approach due to python string's duality. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-19 21:03 Message: Logged In: YES user_id=6380 One problem with ioctl() is that the required length of the buffer is unknown unless you parse the operation code argument in a very platform- (and probably even kernel- and driver-) dependent way. Whether null-terminating it makes sense or not depends on the particular operation code. I don't think the patch makes ioctl "safe", and I'm not sure it even ought to be applied. A quick code review reveals a few more issues: - the docstring doesn't explain the optional "mutate_flag" argument (which BTW is a mess -- read the online docs -- why are we changing the default to true?) - the online docs ought to be updated for 2.4 and again for 2.5 -- they still speak of 2.4 in the future tense! Also, it's a bit strong to say this function is "identical" to fcntl() -- "similar" sounds more like it. - In the first branch of the function, this line: if (mutate_arg && (len < sizeof buf)) { ought to test (len <= sizeof buf) to match the test earlier; but probably better is to use if (mutate_arg && arg == buf) { - If it's important to null-terminate the data in the buffer when a string is passed in, shouldn't we null-terminate it also when a writable buffer-interface object is passed in? If not in the latter case, why if a string is passed? One could argue that a string with an explicit \0 (visible to Python code) at the end ought to be passed in if the semantics of the op code requires a null-terminated argument (which most ioctl op codes don't -- the typical argument is a C struct). - The proposed patch reduces the maximum buffer size to 1023, which violates the docs. (Yes the docs explicitly mention 1024.) - The best we can do seems to be: increase the buffer size to 1025; null-pad it in all cases; change the code for mutable buffers to test for sizeof buf - 1. This still leaves the case where the buffer isn't used because a mutable buffer is passed that's longer than 1024. Which suggests that we can't completely fix this -- it will always be possible to crash Python using this function by passing an op code that encodes a buffer length > 1024 while passing a shorter argument, so the internal buffer is used. I guess we could do the null-padding as long as we document it and document that when a mutable buffer is passed we don't guarantee it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-18 08:14 Message: Logged In: YES user_id=33168 Thomas, could this have caused the flakiness that you just fixed with test_pty? This patch seems correct to me and I think it should be applied. (If you want I can do that, but I wanted you to see this first.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 From noreply at sourceforge.net Wed Apr 12 17:00:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 08:00:23 -0700 Subject: [ python-Bugs-416288 ] infrequent memory leak in pyexpat Message-ID: Bugs item #416288, was opened at 2001-04-15 17:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: douglas orr (dougbo) Assigned to: Nobody/Anonymous (nobody) Summary: infrequent memory leak in pyexpat Initial Comment: In pyexpat.c, the macro call for the handler dispatch (my##NAME##Handler) for CharacterHandler allocates an object implicitly by calling one of the conversion-to- unicode routines. If there is a problem in the PyBuildValue, resulting in args == NULL, that object will be leaked. Low priority, but the macros probably need some reworking to handle this. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 15:00 Message: Logged In: YES user_id=849994 This was fixed in response to bug [ 984722 ] Py_BuildValue loses reference counts on error, in rev. 36480. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 08:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-03-28 23:20 Message: Logged In: YES user_id=21627 No, currently, it can only leak: the argument being passed will have an extra ref count, which supposedly will be consumed by the tuple. If something fails, some of the N arguments will have been stored in the tuple-under-construction, and will be released when the tuple is released. 'N' arguments not yet consumed will leak. Processing should continue in case of an error, and DECREF all N arguments. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-28 22:34 Message: Logged In: YES user_id=6380 Hm, the 'N' format code looks really scary. Can't it end up DECREF'ing an object too many times if something fails? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2001-06-09 11:48 Message: Logged In: YES user_id=21627 That seems to be a bug in Py_BuildValue: It should decref its N arguments if it can't create a tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470 From noreply at sourceforge.net Wed Apr 12 17:19:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 08:19:32 -0700 Subject: [ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__ Message-ID: Bugs item #1367183, was opened at 2005-11-26 21:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getdoc fails on objs that use property for __doc__ Initial Comment: inspect.getdoc has these lines: if not isinstance(doc, types.StringTypes): return None which interfere with the case where __doc__ is some other thing that has a good __str__. I wanted to make a lazy __doc__ that did an expensive lookup of some external documentation only when it was str()'d, but since doc displayers often (correctly) use inspect.getdoc, they were getting None. I think the intention of the test in getdoc() is to avoid trying string operations on a __doc__ that is None. I think that a more lenient version would allow me to do my fancy docstrings but still solve the '__doc__ is None' problem. Please consider the following patch: if doc is None: return None doc = str(doc) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 15:19 Message: Logged In: YES user_id=849994 Closing as Won't Fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 08:04 Message: Logged In: YES user_id=33168 That code doesn't work if doc is unicode. I'm not sure how to achieve what you want. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 08:21 Message: Logged In: YES user_id=1188172 I don't know. Neal, do you have an opinion about property docstrings? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 11:35 Message: Logged In: YES user_id=1344176 It's not a good idea to use properties for __doc__: """ >>> class Foo(object): ... def _get(self): ... return 'the docstring' ... __doc__ = property(_get) ... >>> print Foo().__doc__ the docstring >>> print Foo.__doc__ >>> """ In this light, I don't view inspect.getdoc's lack of support for __doc__-as-property as a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 From noreply at sourceforge.net Wed Apr 12 17:21:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 08:21:35 -0700 Subject: [ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed Message-ID: Bugs item #1248997, was opened at 2005-07-31 21:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Laurie Harper (zodiac) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 15:21 Message: Logged In: YES user_id=849994 This is a duplicate of #1403221. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 08:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-04 05:30 Message: Logged In: YES user_id=21627 Sounds good. Can you provide a patch? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-08-03 22:14 Message: Logged In: YES user_id=2772 I'd rather see the build-requires line of the spec file have the required -devel packages listed, than fix the spec file to detect whether they're available and possibly build a python with reduced capabilities. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 From noreply at sourceforge.net Wed Apr 12 19:01:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 10:01:03 -0700 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 12:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 19:01 Message: Logged In: YES user_id=21627 Sure. Closing it as "won't fix". If the problem persists for 2.5, please re-report. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 16:39 Message: Logged In: YES user_id=849994 As 2.3.x is not maintained anymore, should this be closed? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-12 10:03 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 14:23 Message: Logged In: YES user_id=33168 I think I remember hearing something about an incompatibility. The two best people to discuss this are probably Martin v. Loewis and Fred Drake. I'm assigning to Martin, perhaps he can shed some more light on the issues. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 13:46 Message: Logged In: YES user_id=200117 I have now installed Python-2.3.3 plus PyXML-0.8.3 and the core dump in 'make test' has returned. So, it looks like a compatability problem with PyXML-0.8.3 ? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 10:25 Message: Logged In: YES user_id=200117 HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license This is the configure command I used: base_inst_dir=/opt python_link=${base_inst_dir}/python CC=cc \ OPT="+O2 -z +Onofltacc +ESlit +Oentrysched \ +Odataprefetch +Onolimit +DA2.0" \ INSTALL="./install-sh -c" \ ./configure --with-threads --without-gcc \ --with-cxx=/opt/aCC/bin/aCC --without-libd \ --with-cycle-gc --prefix=$python_link \ --exec-prefix=$python_link This is exactly the same command I have used on previous Python 2.3 releases which did not core dump in 'make test'. Note it uses the native HP compiler. I have now just rebuilt without optimisation, using: CC=cc \ INSTALL="./install-sh -c" \ ./configure --with-threads --without-gcc \ --with-cxx=/opt/aCC/bin/aCC --without-libd \ --with-cycle-gc --prefix=$python_link \ --exec-prefix=$python_link It still core dumps at the same point in the second pass of 'make test'. I have attached a stack trace from the core file. I noticed that this has references to /opt/python/lib/python2.3/site- packages/_xmlplus/parsers/pyexpat.sl. This is the previous installation of Python 2.3.2 plus PyXML-0.8.3. I wondered if I had forgotten to reset $PYTHONPATH before running 'make test', so I did that and tried again but it still core dumped. So next I reset the symbolic link /opt/python to the empty directory /opt/python-2.3.3 and ran 'make test' again. This time it didn't core dump! So why does the test suite access the previous installation when PYTHONPATH doesn't include it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 04:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Apr 12 20:07:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 11:07:35 -0700 Subject: [ python-Feature Requests-960454 ] old/new class documentation Message-ID: Feature Requests item #960454, was opened at 2004-05-25 18:33 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: old/new class documentation Initial Comment: The distributed documentation refers to old and new-style classes, but they do not appear in the index, and the difference is not explained. (Users who ask are referred to documentation on www.python.org, which is not currently shipped with the default distrubution.) As best I understand it, the only differences are: (1) New-style classes inherit from object. Because of this inheritance, new-style classes have a few extra capabilities, such as descriptors and super. (2) Method Resolution Order can be different in cases of multiple inheritance. (3) New style classes take precedence over old-style classes when doing rich comparison. (4) If rich comparison fails, numeric coercion will be attempted if -- and only if -- at least one of the objects is an old-style class. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-04-12 14:07 Message: Logged In: YES user_id=764593 ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-10 10:07 Message: Logged In: YES user_id=1326842 This seems like a duplicate of bug #960340, which was closed when section New-style and classic classes was added to the Python Reference Manual (see http://docs.python.org/dev/ref/node33.html). ---------------------------------------------------------------------- Comment By: Edward Diener (eldiener) Date: 2004-08-01 19:53 Message: Logged In: YES user_id=490593 New style classes, with all their new attributes, member functions, static methods, and class methods, need to be documented in the official Python distribution. Included in this is the explanation of metaclasses and how to use them. Essentially Guido's paper on new style classes, reworked to fit within the existing documentation framework, should be added to the official documantation.. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 11:21 Message: Logged In: YES user_id=764593 Found a new difference -- you can't assign to the __bases__ or __name__ of a new-style class, and you can't usually assign to it's __class__. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 10:05 Message: Logged In: YES user_id=764593 Given that the differences are almost -- but not entirely -- extra options for new-style classes, the language lawyer section on classes (ref/7.6) might be a good location. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 From noreply at sourceforge.net Wed Apr 12 21:21:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 12:21:33 -0700 Subject: [ python-Bugs-1332852 ] BSD DB test failures for BSD DB 3.2 Message-ID: Bugs item #1332852, was opened at 2005-10-19 21:41 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470 Please note that this 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: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: BSD DB test failures for BSD DB 3.2 Initial Comment: After a bunch of modifications to build and get bsddb mostly running, I still get 4 test failures with Python 2.4 and CVS head. FAIL: test_previous_last_looping (test.test_bsddb.TestBTree) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('q', 'Guido'), ('w', 'van'), ('t', 'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestHashTable) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestBTree_InMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('q', 'Guido'), ('w', 'van'), ('t', 'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestHashTable_InMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 12:21 Message: Logged In: YES user_id=413 i'd prefer to just not support 3.2 anymore. mind if i just change setup.py to not accept 3.2? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:20 Message: Logged In: YES user_id=33168 Oops, that last comment got cut off. I've got db-3.2 and db-4.1 on my system at least. Not sure why the older one is picked up rather than the newer one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:17 Message: Logged In: YES user_id=33168 test_bsddb3 core dumps for me. backtrace attached. Do we really support 3.2 anymore? Maybe we shouldn't? I'm on a gentoo system. I don't know wha ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470 From noreply at sourceforge.net Wed Apr 12 21:24:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 12:24:12 -0700 Subject: [ python-Bugs-764839 ] Old bsddb version picked by setup.py Message-ID: Bugs item #764839, was opened at 2003-07-02 12:39 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470 Please note that this 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: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Martin v. L??wis (loewis) Summary: Old bsddb version picked by setup.py Initial Comment: I have two versions of Berkeley DB in the standard include path. The code in setup.py finds the newer version first (db4) and then finds the older version (db3) later in scanning standard includes. This means that the bsddb module is built against the older rather than the newer version. The attached patch to setup.py records all standard headers that are found and lets the db_search_order list choose which version of the library to link against. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 12:24 Message: Logged In: YES user_id=413 the rewrite of the BerkeleyDB version selection code in setup.py i did a while back (last year) should have taken care of this. prior to that it could indeed pick non-matching include and library files. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-10-18 02:51 Message: Logged In: YES user_id=21627 I see. Please notice that setting CFLAGS prior to compilation is not really supported, so I recommend that you don't set CFLAGS - BerkeleyDB 4.1 should still be found in /usr/local, or (preferred) /usr/local/BerkeleyDB.4.1 ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-07-07 09:29 Message: Logged In: YES user_id=693077 I am running Debian GNU/Linux, unstable, with GCC 3.3.1. I added the following to my environment prior to building Python: LDFLAGS=-L${HOME}/local/lib CFLAGS-I${HOME}/local/include My local build of Berkeley DB is version 4.1.25, and the system version is 3.2.9. I hope that makes the situation clear. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-07-06 22:00 Message: Logged In: YES user_id=21627 Can you please be more explicit? What operating system are you using, what compiler, how did you add something to the include path, what was the version of BerkeleyDB that was installed, what was the version that you installed yourself, and where did you install it? In short, you shouldn't add something to the include path. For gcc, I don't even see how you *could* add something to the include path. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-07-06 19:29 Message: Logged In: YES user_id=693077 There is a system Berkeley DB library and I have a locally built newer Berkeley DB library. When building Python, I added my local build to the include path and to the library path. Am I missing a more explicit way of selecting the library short of editing Setup in the Modules directory? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-07-06 02:46 Message: Logged In: YES user_id=21627 I'm not quite sure how this could ever happen. Are you saying that you have two different versions of db.h, both on your standard search path? In what specific locations? This is asking for trouble, and it might be better if setup.py would actively reject that scenario, refusing to build _bsddb. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470 From noreply at sourceforge.net Wed Apr 12 21:55:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 12:55:44 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Paul Moore (pmoore) >Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:12:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:12:30 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-12 22:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:17:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:17:50 -0700 Subject: [ python-Bugs-1149413 ] bsddb: bug with 'n' flag Message-ID: Bugs item #1149413, was opened at 2005-02-22 14:14 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&group_id=5470 Please note that this 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.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Gregory P. Smith (greg) Summary: bsddb: bug with 'n' flag Initial Comment: Where: http://docs.python.org/lib/module-bsddb.html You say there: btopen( filename[, flag[, mode[, btflags[, cachesize[, maxkeypage[, minkeypage[, psize[, lorder]]]]]]]]) the word psize should be replaced with pgsize. An example would help: >>> d = bsddb.btopen(None, "c", cachesize=768000, pgsize=65536) >>> d = bsddb.btopen(None, "n", cachesize=768000, pgsize=65536) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 201, in btopen flags = _checkflag(flag, file) File "/usr/lib/python2.3/bsddb/__init__.py", line 249, in _checkflag if os.path.isfile(file): File "/usr/lib/python2.3/posixpath.py", line 200, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, NoneType found >>> The latter is I believe possibly a bug in the python wrapper not handling 'n' properly. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:17 Message: Logged In: YES user_id=413 fix for the 'n' flag not working with a filename of None committed (with a test case). svn rev 45318. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 14:57 Message: Logged In: YES user_id=11375 I've fixed the documentation to use the right parameter name; thanks for reporting this! The example you give doesn't work for me: it reports 'bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- set_cachesize: method meaningless in shared environment')' with the current CVS head. Removing the cachesize argument makes it work. The 'n' problem does seem to be a bug; the code should check that file is not None before doing os.file.exists(). Reassigning and reclassifying the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:39:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:39:16 -0700 Subject: [ python-Bugs-1117761 ] BSDDB openhash Message-ID: Bugs item #1117761, was opened at 2005-02-07 01:24 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&group_id=5470 Please note that this 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.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Andrea Bolzonella (bolzonella) >Assigned to: Gregory P. Smith (greg) Summary: BSDDB openhash Initial Comment: Python 2.4 (#1, Dec 8 2004, 18:57:30) [GCC 3.3.3 (SuSE Linux)] on linux2 >>> import bsddb >>> h = bsddb.hashopen('test','c',cachesize=100) Traceback (most recent call last): File "", line 1, in ? File "/home/alex/DLD/lib/python2.4/bsddb/__init__.py", line 288, in hashopen bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- DB->set_cachesize: method not permitted in shared environment') I replace bsddb.hashopen with a 2.3.3 version and it works. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:39 Message: Logged In: YES user_id=413 fixed in python repository. commits 45319 and 45320 for 2.5 and 2.4. set_cachesize needed to be called on the DBEnv object prior to opening now instead of the DB object. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-02-09 16:33 Message: Logged In: YES user_id=21627 Apparently, this is caused by hashopen now allocated a DBEnv. This, in turn, is necessary to allow multiple threads to access the same database simultaneously. I'm unsure why bsddb does not support shared access and having a cache size simultaneously; it might be best to disallow the cachesize argument, and require users who want to specify it to use DB.open explicitly (with no environment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:41:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:41:57 -0700 Subject: [ python-Bugs-1215023 ] bsddb dbobj.DB.associate doesn't accept dbobj.DB param Message-ID: Bugs item #1215023, was opened at 2005-06-04 19:18 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215023&group_id=5470 Please note that this 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: 3 Submitted By: Gregory P. Smith (greg) >Assigned to: Gregory P. Smith (greg) Summary: bsddb dbobj.DB.associate doesn't accept dbobj.DB param Initial Comment: To: Michael C Urban Cc: pybsddb-users at lists.sourceforge.net Date: Sat, 4 Jun 2005 18:21:34 -0700 On Sat, Jun 04, 2005 at 06:16:37PM -0500, Michael C Urban wrote: > Hi all, > > I'm running into a TypeError when I try to associate a secondary db with a > primary one. But the error only occurs when I use an object oriented > style, so I am wondering it it might be a bug. > > Basically, the following works fine: > > db = DB(None, 0) > db.open("testDb.db", None, DB_BTREE, DB_CREATE, 0660) > dbs = DB(None, 0) > dbs.open("testDbS.db", None, DB_BTREE, DB_CREATE, 0660) > db.associate(dbs, makeAddressKey, 0) > > However, the following similar code does not: > > def __dbInitialize(self, dbDir, fileName): > self.__dbEnv = dbobj.DBEnv(0) > self.__dbEnv.open(dbDir, db.DB_INIT_TXN | db.DB_CREATE | > db.DB_INIT_MPOOL) > > self.__dbMain = dbobj.DB(self.__dbEnv, 0) > self.__nameIdx = dbobj.DB(self.__dbEnv, 0) > > self.__dbMain.open(fileName, None, db.DB_BTREE, db.DB_CREATE, 0660) > self.__nameIdx.open("nameDb.idx", None, db.DB_BTREE, > db.DB_CREATE, 0660) > > self.__dbMain.associate(self.__nameIdx, self.__makeNameKey, 0) > > ... > The last line causes the following error: > > TypeError: Expected DB argument, instance found. > > Am I doing something wrong here? The only difference I can see between the > first example and the second one is that one uses a private variable from > the class, and the other does not use object oriented style. The databases > all get created fine, as to the log files. It's only when I try to > associate that I have the problem. > > Thanks for any help in advance. This is happening because the C wrapper requires that the secondaryDB parameter to associate() is a C wrapper DB object. My first suggestion is based on the code above, use db.DB not dbobj.DB. dbobj is only a wrapper around the C db.DB to allow people to subclass it. If you do need to use a dbobj derived class for the secondary DB, realize that BerkeleyDB doesn't call back to python for DB access so it won't use any overridden methods. If thats ok, then add the following overridden method to your dbobj derived class and associate should work: 
    def associate(self, *args, **kwargs):
        # if we're given a dbobj derived secondaryDB we
need to pass
        # the actual C db.DB object to BerkeleyDB.  do it.
        argDB = kwargs.get('secondaryDB')
        if not argDB:
            argDB = args.pop(0)
        if isinstance(argDB, DB):
            kwargs['secondaryDB'] = argDB._cobj
        return apply(self._cobj.associate, args, kwargs)
This passes the internal C db.DB object to the BerkeleyDB associate method. I'm pasting this email as a pybsddb bug report. the above method should probably be used as the base dbobj.associate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215023&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:44:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:44:40 -0700 Subject: [ python-Bugs-1010645 ] bsddb3 testsuite failure when running more than one time Message-ID: Bugs item #1010645, was opened at 2004-08-17 03:39 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010645&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) >Assigned to: Gregory P. Smith (greg) Summary: bsddb3 testsuite failure when running more than one time Initial Comment: running the testsuite with TESTOPTS="-l -unetwork,bsddb" leaves (sometimes?) an directory Lib/test/db_home, which lets two of the bsddb tests fail in further test runs. Removing this directory before the next test run, lets the tests complete sucessfully. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:44 Message: Logged In: YES user_id=413 yes there appear to be several messy turds (db_home/ and even a db created outside of db_home) in the existing full bsddb test suite. its on my list to find and clean up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010645&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:49:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:49:37 -0700 Subject: [ python-Bugs-1469498 ] Exception when handling http response Message-ID: Bugs item #1469498, was opened at 2006-04-12 20: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=1469498&group_id=5470 Please note that this 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 Submitted By: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 From noreply at sourceforge.net Wed Apr 12 22:50:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 13:50:05 -0700 Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings Message-ID: Bugs item #781614, was opened at 2003-08-01 10:04 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:50 Message: Logged In: YES user_id=413 I believe BerkeleyDB 4.4 when compiled on windows uses the multithreaded DLL C RTL by default even for its static library now so this error should go away? i think this problem is gone for the latest BerkeleyDB and is just a PCbuild readme.txt documentation problem for older BerkeleyDB versions. in the past for stand alone pybsddb bsddb3 packages i always had to change the static build settings of BerkeleyDB to use multi-threaded DLL code generation (/MD flag on cl.exe). With 4.4 i didn't need to do that. (note we weren't linking with the berkeleydb DLL; its the berkeleydb static library, its just that a python extension module is a DLL so the static library code needed to use the same memory model) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-18 12:18 Message: Logged In: YES user_id=11105 Potentially dangerous - of course. The question is whether this is responsible for some bugs or not. If we cannot link to the DLL then we have to change the build settings for the static builds of libdb41s.lib. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-02-18 11:58 Message: Logged In: YES user_id=21627 I think we should avoid linking with the DLL if possible; in some application context, it may be impossible to find the DLL dynamically, or there might be confusion which DLL to load. The linker warning means that there is a conflict between the static (libc.a) and dynamic (msvcr71.dll) version of _free, etc, which potentially means that we are linking conflicting copies of the CRT, which is potentially dangerous. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-18 09:41 Message: Logged In: YES user_id=11105 It looks to me like we could link to the import library build_win32\Release\libdb41.lib instead of the static library build_win32\Release_static\libdb41s.lib. The former is built with 'multithreaded dll' flags. The downside is that libdb41.dll plus MSVCP60.DLL would have to be distributed. Are the linker warnings a real problem, or only cosmetical? Of course we have to update the build procedure for 2.4 anyway... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-16 15:54 Message: Logged In: YES user_id=31435 Thomas, you have any insight into this one? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-08-01 12:50 Message: Logged In: YES user_id=21627 Can you propose a specific patch? Also, it would be preferable if changing the source code of the Sleepycat distribution would not be necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 From noreply at sourceforge.net Wed Apr 12 23:31:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 14:31:22 -0700 Subject: [ python-Bugs-1469498 ] Exception when handling http response Message-ID: Bugs item #1469498, was opened at 2006-04-12 20:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 Please note that this 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 Submitted By: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:31 Message: Logged In: YES user_id=849994 On which version of Python does this occur? In HEAD, all code paths in begin() lead to self.length being set to some value or None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 From noreply at sourceforge.net Wed Apr 12 23:43:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 14:43:23 -0700 Subject: [ python-Bugs-1469498 ] Exception when handling http response Message-ID: Bugs item #1469498, was opened at 2006-04-12 20:49 Message generated for change (Comment added) made by rkasperski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 Please note that this 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 Submitted By: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None ---------------------------------------------------------------------- >Comment By: Richard Kasperski (rkasperski) Date: 2006-04-12 21:43 Message: Logged In: YES user_id=520350 Here is the version header from running python at the command line. Python 2.4 (#1, Feb 3 2005, 08:52:54 In my httplib.py length is initialized to _UNKNOWN which has the value "UNKNOWN" ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:31 Message: Logged In: YES user_id=849994 On which version of Python does this occur? In HEAD, all code paths in begin() lead to self.length being set to some value or None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 From noreply at sourceforge.net Wed Apr 12 23:50:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 14:50:15 -0700 Subject: [ python-Bugs-1469498 ] Exception when handling http response Message-ID: Bugs item #1469498, was opened at 2006-04-12 20:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 Please note that this 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 Submitted By: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:50 Message: Logged In: YES user_id=849994 It looks like you're getting a HTTP 0.9 response. In Python 2.4.0, self.length wasn't set in this case, but this bug was fixed in version 2.4.2. Closing this as Fixed, if the problem persists with Python 2.4.3 please reopen. ---------------------------------------------------------------------- Comment By: Richard Kasperski (rkasperski) Date: 2006-04-12 21:43 Message: Logged In: YES user_id=520350 Here is the version header from running python at the command line. Python 2.4 (#1, Feb 3 2005, 08:52:54 In my httplib.py length is initialized to _UNKNOWN which has the value "UNKNOWN" ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:31 Message: Logged In: YES user_id=849994 On which version of Python does this occur? In HEAD, all code paths in begin() lead to self.length being set to some value or None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 From noreply at sourceforge.net Thu Apr 13 01:35:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 16:35:47 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-05 01:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 01:35 Message: Logged In: YES user_id=1326842 This was changed again in revision 45316. The current comment in genobject.h says: Note: gi_frame can be NULL if the generator is "finished" ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-05 01:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Thu Apr 13 01:54:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 16:54:18 -0700 Subject: [ python-Bugs-1469548 ] Build requires already built Python Message-ID: Bugs item #1469548, was opened at 2006-04-12 19:54 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=1469548&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: Build requires already built Python Initial Comment: On RedHat 7.1 I ran into the following interesting build bug: $ ./configure (works fine) $ make ./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl File "./Parser.asdl_c.py", line 56 j += 2 # account or the brase and space after it ^ SyntaxError: invalid syntax This is because Python 1.5.2 is the default there -- OK, no problem working around that 'cause I've got other versions there but it seems mighty strange that the very first thing done in a build of Python requires an already-built Python. What happens on an OS where Python isn't there yet at all? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469548&group_id=5470 From noreply at sourceforge.net Thu Apr 13 02:12:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 17:12:02 -0700 Subject: [ python-Bugs-1436428 ] urllib has trouble with Windows filenames Message-ID: Bugs item #1436428, was opened at 2006-02-22 07:03 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470 Please note that this 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 Submitted By: Donovan Eastman (dpeastman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has trouble with Windows filenames Initial Comment: When you pass urllib the name of a local file including a Windows drive letter (e.g. 'C:\dir\My File.txt') URLopener.open() incorrectly interprets the drive letter as the scheme of a URL. Of course, given that there is no scheme 'C', this fails. I have solved this in my own code by putting the following test before calling urllib.urlopen(): if url[1] == ':' and url[0].isalpha(): url = 'file:' + url Although this works fine in my particular case, it seems like urllib should just simply "do the right thing" without having to worry about it. Therefore I propose that urllib should automatically assume that any URL that begins with a single alpha followed by a colon is a local file. The only potential downside would be that it would preclude the use of single letter scheme names. I did a little research on this. RFC 3986 suggests, but does not explicitly state that scheme names must be more than one character. (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme) . That said, there are no currently recognized single letter scheme names (http://www.iana.org/assignments/uri-schemes.html) and it seems very unlikely that there every would be. I would gladly write the code for this myself -- but I suspect that it would take someone longer to review and integrate my changes than it would to just write the code. Thanks, Donovan ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 02:12 Message: Logged In: YES user_id=1326842 There are already two platform specific functions in urllib module just for this purpose: pathname2url and url2pathname. See http://docs.python.org/lib/module-urllib.html#l2h-3193. I agree that this should be closed as invalid. ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-03-20 18:41 Message: Logged In: YES user_id=311085 Filepaths aren't URIs and attempting to hide the difference in the backend is doomed to fail (as it did for SAX). Throw filenames with colons in, network paths, Mac paths and RISC OS paths into the mix, and you've got a situation where it is all but impossible to handle correctly. In any case, the docs *don't* say you can pass in a filepath: If the URL does not have a scheme identifier, or if it has file: as its scheme identifier, this opens a local file This means the string you pass in is unequivocally a URL *not* a pathname... just that you can leave the scheme prefix off for file: URLs. Effectively this is a relative URL. r'C:\spam' is *not* a valid way to refer to a local file using a relative URL. Pass it through pathname2url and you'll get '///C|/spam', which is okay; 'C|/spam' and '/C|span' will also work. Even on Unix, a filepath won't always work when passed to urlopen. Filenames can have percent signs in, which have to be encoded in URLs, for example. Always use pathname2url or you're going to trip up. (Suggest setting status INVALID, possible clarification to docs to warn against passing a filepath to urlopen?) ---------------------------------------------------------------------- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-14 03:32 Message: Logged In: YES user_id=757799 OK - Here's my suggested fix: This can be fixed with a single if statement (and a comment to explain it to confused unix programmers). In splittype(), right after the line that reads: scheme = match.group(1) add the following: #ignore single char schemes to avoid confusion with win32 drive letters if len(scheme) > 1: ...and indent the next line. Alternatively, the if statement could read: if len(scheme) > 1 or sys.platform != 'win32': ...which would allow single letter scheme names on non-Windows systems. I would argue that it is better to be consistent and have it work the same way on all OS's. ---------------------------------------------------------------------- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-14 02:56 Message: Logged In: YES user_id=757799 Reasons why urllib should open local files: 1) This allows you to write code that handles local files and Internet files equally well -- without having to do any special magic of your own. 2) The docs all say that it should. I believe this would work just fine under Unix. In URLopener.open() it looks for the protocol prefix and if it can't find one, it assumes that it is a local file. The problem on Windows is that you have these pesky drive letters. The form 'C:\location' ends up looking a lot like the form 'http://location'. Therefore it looks for a protocol called 'c' -- which obviously isn't going to work. ---------------------------------------------------------------------- Comment By: Koen van de Sande (shadowmorpher) Date: 2006-03-13 20:19 Message: Logged In: YES user_id=270334 Why should the URL lib module support opening of local files? It already does so through the file: protocol prefix, and do not see why it should support automatic detection of Windows filenames. AFAIK it does not do automatic detection of Unix filenames (one could recognize it from /home/ something), so why would Windows work differently? I'm not an expert or anything, so I might be wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&group_id=5470 From noreply at sourceforge.net Thu Apr 13 02:13:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 17:13:57 -0700 Subject: [ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions Message-ID: Bugs item #1469557, was opened at 2006-04-12 17:13 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=1469557&group_id=5470 Please note that this 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 Submitted By: Bruce (brucepeterson) Assigned to: Nobody/Anonymous (nobody) Summary: FTP modue functions are not re-entrant,give odd exceptions Initial Comment: If I define a class using the Thread and FTP moudles, start a process which gathers FTP responses, additional calls to the class may have the responses of the thread instead of the main loop (or vice versa) This causes weird and unexpected exceptions from the ftplib. For instance I get the following error when the thread process does a pwd() function error_reply: 213 34603008 The "213" reply is a response from the main process size() function --------- Code --------- from time import sleep from threading import Thread class ftpMachine(Thread, ftplib.FTP): def __init__(self, svr, user, passwd): Thread.__init__(self) ftplib.FTP.__init__(self, svr, user, passwd) def run(self): for x in xrange(20): output="Thread -"+str(self.nlst())[:30] print output sleep (0.0100) def main(): aCon = ftpMachine("LocalFTP", "user", "") aCon.start() for x in xrange(20): output = "Main -- " + str(aCon.size("File")) print output sleep (0.010) Workround: Rewrite code to create a third worker thread for response isolation? Don't know that this would solve the problem. --------------- Exception example --------------- Exception in thread Thread-1: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "dualFTPIssue.py", line 17, in run output = "Thread output " + str(self.nlst())[:30] +" ..." File "C:\Python24\lib\ftplib.py", line 448, in nlst self.retrlines(cmd, files.append) File "C:\Python24\lib\ftplib.py", line 396, in retrlines conn = self.transfercmd(cmd) File "C:\Python24\lib\ftplib.py", line 345, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "C:\Python24\lib\ftplib.py", line 321, in ntransfercmd host, port = self.makepasv() File "C:\Python24\lib\ftplib.py", line 299, in makepasv host, port = parse227(self.sendcmd('PASV')) File "C:\Python24\lib\ftplib.py", line 566, in parse227 raise error_reply, resp error_reply: 213 34603008 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470 From noreply at sourceforge.net Thu Apr 13 04:18:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 19:18:57 -0700 Subject: [ python-Bugs-1469548 ] Build requires already built Python Message-ID: Bugs item #1469548, was opened at 2006-04-13 09:54 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469548&group_id=5470 Please note that this 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: Build requires already built Python Initial Comment: On RedHat 7.1 I ran into the following interesting build bug: $ ./configure (works fine) $ make ./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl File "./Parser.asdl_c.py", line 56 j += 2 # account or the brase and space after it ^ SyntaxError: invalid syntax This is because Python 1.5.2 is the default there -- OK, no problem working around that 'cause I've got other versions there but it seems mighty strange that the very first thing done in a build of Python requires an already-built Python. What happens on an OS where Python isn't there yet at all? ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-13 12:18 Message: Logged In: YES user_id=29957 This is a packaging bug. You can workaround it with 'touch Python/Python-ast.c Python/Python-ast.h' before running make. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469548&group_id=5470 From noreply at sourceforge.net Thu Apr 13 05:20:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 20:20:08 -0700 Subject: [ python-Bugs-1332852 ] BSD DB test failures for BSD DB 3.2 Message-ID: Bugs item #1332852, was opened at 2005-10-19 21:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470 Please note that this 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: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: BSD DB test failures for BSD DB 3.2 Initial Comment: After a bunch of modifications to build and get bsddb mostly running, I still get 4 test failures with Python 2.4 and CVS head. FAIL: test_previous_last_looping (test.test_bsddb.TestBTree) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('q', 'Guido'), ('w', 'van'), ('t', 'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestHashTable) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestBTree_InMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('q', 'Guido'), ('w', 'van'), ('t', 'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestHashTable_InMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-12 20:20 Message: Logged In: YES user_id=33168 I don't mind and think it's reasonable to set whatever minimum version for 2.5. I don't think 3.2 support should be removed from 2.4 though. In 2.4, you can print a message in setup.py if the version is too old. I think that's conservative enough and reasonble. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-04-12 12:21 Message: Logged In: YES user_id=413 i'd prefer to just not support 3.2 anymore. mind if i just change setup.py to not accept 3.2? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:20 Message: Logged In: YES user_id=33168 Oops, that last comment got cut off. I've got db-3.2 and db-4.1 on my system at least. Not sure why the older one is picked up rather than the newer one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:17 Message: Logged In: YES user_id=33168 test_bsddb3 core dumps for me. backtrace attached. Do we really support 3.2 anymore? Maybe we shouldn't? I'm on a gentoo system. I don't know wha ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470 From noreply at sourceforge.net Thu Apr 13 07:04:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 22:04:48 -0700 Subject: [ python-Bugs-1469629 ] __dict__ = self in subclass of dict causes a memory leak? Message-ID: Bugs item #1469629, was opened at 2006-04-13 05: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=1469629&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) Summary: __dict__ = self in subclass of dict causes a memory leak? Initial Comment: Using: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 For reasons I do not understand, the following class leaks itself continuously: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) self.__dict__ = self Whereas this version does not: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) def __getattr__(self, key): return self[key] def __setattr__(self, key, value): self[key] = value My test looks like this: for n in xrange(1000000): import gc gc.collect() ad = AttrDict() ad['x'] = n ad.y = ad.x print n, ad.x, ad.y And I sit and watch in the windows task manager while the process grows and grows. With the __getattr__ version, it doesn't grow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 From noreply at sourceforge.net Thu Apr 13 07:11:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 22:11:40 -0700 Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings Message-ID: Bugs item #781614, was opened at 2003-08-01 19:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-13 07:11 Message: Logged In: YES user_id=21627 Right. This problem was fixed with r43002. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-04-12 22:50 Message: Logged In: YES user_id=413 I believe BerkeleyDB 4.4 when compiled on windows uses the multithreaded DLL C RTL by default even for its static library now so this error should go away? i think this problem is gone for the latest BerkeleyDB and is just a PCbuild readme.txt documentation problem for older BerkeleyDB versions. in the past for stand alone pybsddb bsddb3 packages i always had to change the static build settings of BerkeleyDB to use multi-threaded DLL code generation (/MD flag on cl.exe). With 4.4 i didn't need to do that. (note we weren't linking with the berkeleydb DLL; its the berkeleydb static library, its just that a python extension module is a DLL so the static library code needed to use the same memory model) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-18 21:18 Message: Logged In: YES user_id=11105 Potentially dangerous - of course. The question is whether this is responsible for some bugs or not. If we cannot link to the DLL then we have to change the build settings for the static builds of libdb41s.lib. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-02-18 20:58 Message: Logged In: YES user_id=21627 I think we should avoid linking with the DLL if possible; in some application context, it may be impossible to find the DLL dynamically, or there might be confusion which DLL to load. The linker warning means that there is a conflict between the static (libc.a) and dynamic (msvcr71.dll) version of _free, etc, which potentially means that we are linking conflicting copies of the CRT, which is potentially dangerous. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-18 18:41 Message: Logged In: YES user_id=11105 It looks to me like we could link to the import library build_win32\Release\libdb41.lib instead of the static library build_win32\Release_static\libdb41s.lib. The former is built with 'multithreaded dll' flags. The downside is that libdb41.dll plus MSVCP60.DLL would have to be distributed. Are the linker warnings a real problem, or only cosmetical? Of course we have to update the build procedure for 2.4 anyway... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-17 00:54 Message: Logged In: YES user_id=31435 Thomas, you have any insight into this one? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-08-01 21:50 Message: Logged In: YES user_id=21627 Can you propose a specific patch? Also, it would be preferable if changing the source code of the Sleepycat distribution would not be necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 From noreply at sourceforge.net Thu Apr 13 08:59:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Apr 2006 23:59:50 -0700 Subject: [ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3 Message-ID: Bugs item #1467450, was opened at 2006-04-10 03:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470 Please note that this 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 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on OSX 10.3 Initial Comment: test test_ctypes failed -- Traceback (most recent call last): File "/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py", line 30, in test_load cdll.load(libc_name) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 153, in _load return self.load_library(pathname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlcompat: unable to open this file with RTLD_LOCAL This happens both with and without the patch in r43748. Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc GCC version: Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-13 08:59 Message: Logged In: YES user_id=11105 I'm trying to get a copy of OS X 10.3, then will try to install it and look after this problem. OTOH, the ctypes loading code is currently rewritten in the upstream version - this will probably prevent this failure. In the meantime, can you try to find out the cause of this failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is the library file missing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470 From noreply at sourceforge.net Thu Apr 13 09:29:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 00:29:33 -0700 Subject: [ python-Bugs-1445210 ] embedding Python causes memory leaks Message-ID: Bugs item #1445210, was opened at 2006-03-08 00:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andrew Trevorrow (andykt) Assigned to: Nobody/Anonymous (nobody) Summary: embedding Python causes memory leaks Initial Comment: [This bug has been submitted by others but for some reason it has been marked Closed. I consider it to be an extremely serious bug -- if I can't solve it I'm going to have to abandon Python as my app's scripting language, even though I've fallen in love!] I've added Python script support to my cross-platfom wxWidgets app so that users can run .py scripts from within the app to automate the GUI and do other fancy things. It all works very nicely, except for one nasty problem: *every* time a script is run there is a memory leak, usually small (about 10K) but sometimes massive (about 4MB in the case of one rather complicated script). The problem occurs on both Mac OS 10.3.9 and Windows 2000. I'm using Python 2.3 on the Mac and 2.4.2 on Windows. Every time the user runs a script, my app makes these calls: (I've removed a lot of irrelevant stuff.) Py_Initialize(); PyRun_SimpleString("execfile('foo.py')"); Py_Finalize(); It's definitely not a wxWidgets problem. In fact it's quite easy to see the memory leak using a simple command-line program: #include #include main(int argc, char *argv[]) { int i; for (i=0; i<1000; i++) { Py_Initialize(); Py_Finalize(); printf("."); if ((i+1) % 50 == 0) printf("\n"); } } Note that it doesn't even execute a script. If I run this program on my Mac and watch its memory usage with Activity Monitor, I see a leak of about 10K each time through the loop. Similar result on Windows. Curiously, on both machines, the Py_Finalize() call takes longer and longer to complete whatever it's doing. The above program takes a few *minutes* to complete on my 400MHz Mac. Andrew ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-13 09:29 Message: Logged In: YES user_id=21627 That the documentation claims Py_Finalize releases all memory is a bug; I just fixed this in r45344. The original problem cannot be fixed (atleast not until Python 3000); closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-10 06:43 Message: Logged In: YES user_id=1281947 See http://evanjones.ca/python-memory.html for some useful info. Apparently the Python memory allocator never releases memory back to the OS! So if a complicated script happens to consume 100MB of interpreter memory then that amount is no longer available to the app in which Python is embedded. Even worse, if a script has a (Python) memory leak then there's nothing the app can do about it. It would be great if wrapping each script inside Py_Initialize/Py_Finalize could avoid all that. There should be some way to tell Python "release all the memory you've ever allocated and start again with a clean slate". ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 10:50 Message: Logged In: YES user_id=1281947 Bloody hell -- sorry for the bad line breaks. One day I'll figure out how to use sf properly! ---------------------------------------------------------------------- Comment By: Andrew Trevorrow (andykt) Date: 2006-03-08 10:46 Message: Logged In: YES user_id=1281947 > Why do you call Py_Initialize/Py_Finalize more than once? How else do I tell Python to free up memory after each PyRun_SimpleString call? I want users to be able to run scripts many times from within my app. If I just keep calling PyRun_SimpleString then my app will leak more and more memory until it becomes unusable. >From http://docs.python.org/api/embedding.html: Sometimes, it is desirable to ``uninitialize'' Python. For instance, the application may want to start over (make another call to Py_Initialize()) or the application is simply done with its use of Python and wants to free all memory allocated by Python. This can be accomplished by calling Py_Finalize(). That's exactly what I want to do. I want the interpreter to run a script and then release all the resources used by that script. Unfortunately, Py_Finalize does *not* restore memory usage to what it was before the Py_Initialize call. I wouldn't mind if there was a one-off allocation cost (the 1st time Py_Initialize is called), but my app is leaking more memory *every* time a script is run! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-08 09:32 Message: Logged In: YES user_id=33168 Why do you call Py_Initialize/Py_Finalize more than once? Why not do something like this (I'm kinda mixing C and Python for convenience): /* startup */ Py_Initialize(); /* do whatever */ while (moreFiles()) { PyRun_SimpleString("execfile('%s')" % nextFile()); /* do whatever */ } /* shutdown */ Py_Finalize(); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&group_id=5470 From noreply at sourceforge.net Thu Apr 13 11:58:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 02:58:46 -0700 Subject: [ python-Bugs-1469629 ] __dict__ = self in subclass of dict causes a memory leak? Message-ID: Bugs item #1469629, was opened at 2006-04-13 05:04 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) Summary: __dict__ = self in subclass of dict causes a memory leak? Initial Comment: Using: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 For reasons I do not understand, the following class leaks itself continuously: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) self.__dict__ = self Whereas this version does not: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) def __getattr__(self, key): return self[key] def __setattr__(self, key, value): self[key] = value My test looks like this: for n in xrange(1000000): import gc gc.collect() ad = AttrDict() ad['x'] = n ad.y = ad.x print n, ad.x, ad.y And I sit and watch in the windows task manager while the process grows and grows. With the __getattr__ version, it doesn't grow. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-04-13 09:58 Message: Logged In: YES user_id=4771 This is caused by the tp_clear not doing its job -- in this case, tp_clear is subtype_clear(), which does not reset the __dict__ slot to NULL because it assumes that the __dict__ slot's content itself will be cleared, which is perfectly true but doesn't help if self.__dict__ is self. Attached a patch to fix this. It's kind of hard to test for this bug because all instances of AttrDict are really cleared, weakrefs to them are removed, etc. Also attached is an example showing a similar bug: a cycle through the ob_type field, with a object U whose class is itself. It is harder to clear this link because we cannot just set ob_type to NULL in subtype_clear. Ideas welcome... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 From noreply at sourceforge.net Thu Apr 13 13:00:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 04:00:30 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 14:17 Message generated for change (Comment added) made by vnainar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: nomind (vnainar) Date: 2006-04-13 16:30 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 11:02 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 10:43 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 03:58 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-11 02:54 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 02:28 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 19:18 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 17:44 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 16:21 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 16:16 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 15:59 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:36 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 11:08 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 03:46 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Thu Apr 13 14:50:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 05:50:13 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-04 19:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 08:50 Message: Logged In: YES user_id=11375 I've added a mention of this page to the "What's New"; thanks for the suggestion! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-12 19:35 Message: Logged In: YES user_id=1326842 This was changed again in revision 45316. The current comment in genobject.h says: Note: gi_frame can be NULL if the generator is "finished" ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-04 19:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Thu Apr 13 15:01:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 06:01:15 -0700 Subject: [ python-Bugs-1447031 ] whatsnew 2.5: pep 353, python -m Message-ID: Bugs item #1447031, was opened at 2006-03-10 02:44 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447031&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Gene Tani (gtani) Assigned to: A.M. Kuchling (akuchling) Summary: whatsnew 2.5: pep 353, python -m Initial Comment: http://docs.python.org/dev/whatsnew/whatsnew25.html I don't see mention of PEP 353 (indexing with ssize_t) or the python -m switch, as per: http://agiletesting.blogspot.com/2006/02/pycon-notes-part-2-guidos-keynote.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 09:01 Message: Logged In: YES user_id=11375 The "What's New" was greatly expanded in March, and there are now sections on these two topics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447031&group_id=5470 From noreply at sourceforge.net Thu Apr 13 15:30:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 06:30:20 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-05 01:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 15:30 Message: Logged In: YES user_id=1326842 I don't think that your change is correct anymore; Philip J. Eby has changed the behaviour again in revision 45316. The log for his checkin says: Don't set gi_frame to Py_None, use NULL instead, eliminating some insane pointer dereferences. See: http://mail.python.org/pipermail/python-dev/2006-April/063647.html http://mail.python.org/pipermail/python-checkins/2006-April/051180.html for more details. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 14:50 Message: Logged In: YES user_id=11375 I've added a mention of this page to the "What's New"; thanks for the suggestion! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 01:35 Message: Logged In: YES user_id=1326842 This was changed again in revision 45316. The current comment in genobject.h says: Note: gi_frame can be NULL if the generator is "finished" ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-05 01:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Thu Apr 13 15:40:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 06:40:00 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-04 19:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 09:40 Message: Logged In: YES user_id=11375 No, it's correct; I verified it with a small test program. Whether PJE's code uses Py_None or NULL, you still get a None in your Python code. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 09:30 Message: Logged In: YES user_id=1326842 I don't think that your change is correct anymore; Philip J. Eby has changed the behaviour again in revision 45316. The log for his checkin says: Don't set gi_frame to Py_None, use NULL instead, eliminating some insane pointer dereferences. See: http://mail.python.org/pipermail/python-dev/2006-April/063647.html http://mail.python.org/pipermail/python-checkins/2006-April/051180.html for more details. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 08:50 Message: Logged In: YES user_id=11375 I've added a mention of this page to the "What's New"; thanks for the suggestion! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-12 19:35 Message: Logged In: YES user_id=1326842 This was changed again in revision 45316. The current comment in genobject.h says: Note: gi_frame can be NULL if the generator is "finished" ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-04 19:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Thu Apr 13 15:44:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 06:44:42 -0700 Subject: [ python-Bugs-1464571 ] Changes to generator object's gi_frame attr Message-ID: Bugs item #1464571, was opened at 2006-04-05 01:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 15:44 Message: Logged In: YES user_id=1326842 Oops, my previous comment is only relevant for C code. Sorry for the noise. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 15:40 Message: Logged In: YES user_id=11375 No, it's correct; I verified it with a small test program. Whether PJE's code uses Py_None or NULL, you still get a None in your Python code. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 15:30 Message: Logged In: YES user_id=1326842 I don't think that your change is correct anymore; Philip J. Eby has changed the behaviour again in revision 45316. The log for his checkin says: Don't set gi_frame to Py_None, use NULL instead, eliminating some insane pointer dereferences. See: http://mail.python.org/pipermail/python-dev/2006-April/063647.html http://mail.python.org/pipermail/python-checkins/2006-April/051180.html for more details. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-04-13 14:50 Message: Logged In: YES user_id=11375 I've added a mention of this page to the "What's New"; thanks for the suggestion! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-13 01:35 Message: Logged In: YES user_id=1326842 This was changed again in revision 45316. The current comment in genobject.h says: Note: gi_frame can be NULL if the generator is "finished" ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-05 01:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 From noreply at sourceforge.net Thu Apr 13 21:13:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 12:13:54 -0700 Subject: [ python-Bugs-1470026 ] distutils.core: link to list of Trove classifiers Message-ID: Bugs item #1470026, was opened at 2006-04-13 12:13 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=1470026&group_id=5470 Please note that this 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 Submitted By: Ansel Halliburton (anseljh) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.core: link to list of Trove classifiers Initial Comment: In 10.1 (distutils.core), it would be nice to have a link to the full list of Trove classifiers. There is already a place for such a link in the table for the setup() method; search for "XXX link to better definition". Here is the link to add: http://www.python.org/pypi?:action=list_classifiers I would say "a list of strings; see http://www.python.org/pypi?:action=list_classifiers for a list of all possible values" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470026&group_id=5470 From noreply at sourceforge.net Thu Apr 13 21:20:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 12:20:09 -0700 Subject: [ python-Bugs-1332852 ] BSD DB test failures for BSD DB 3.2 Message-ID: Bugs item #1332852, was opened at 2005-10-19 21:41 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470 Please note that this 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: Closed Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: BSD DB test failures for BSD DB 3.2 Initial Comment: After a bunch of modifications to build and get bsddb mostly running, I still get 4 test failures with Python 2.4 and CVS head. FAIL: test_previous_last_looping (test.test_bsddb.TestBTree) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('q', 'Guido'), ('w', 'van'), ('t', 'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestHashTable) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestBTree_InMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('q', 'Guido'), ('w', 'van'), ('t', 'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ====================================================================== FAIL: test_previous_last_looping (test.test_bsddb.TestHashTable_InMemory) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 128, in test_previous_last_looping self.assertSetEquals(items, self.d.items()) File "/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py", line 55, in assertSetEquals self.assertEqual(Set(seqn1), Set(seqn2)) AssertionError: Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r', 'invented'), ('t', 'Python'), ('w', 'van'), ('q', 'Guido'), ('y', '')]) ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-04-13 12:20 Message: Logged In: YES user_id=413 ok i've raised the minimum to 3.3 in python 2.5 trunk. svn r45368. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-12 20:20 Message: Logged In: YES user_id=33168 I don't mind and think it's reasonable to set whatever minimum version for 2.5. I don't think 3.2 support should be removed from 2.4 though. In 2.4, you can print a message in setup.py if the version is too old. I think that's conservative enough and reasonble. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-04-12 12:21 Message: Logged In: YES user_id=413 i'd prefer to just not support 3.2 anymore. mind if i just change setup.py to not accept 3.2? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:20 Message: Logged In: YES user_id=33168 Oops, that last comment got cut off. I've got db-3.2 and db-4.1 on my system at least. Not sure why the older one is picked up rather than the newer one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-19 22:17 Message: Logged In: YES user_id=33168 test_bsddb3 core dumps for me. backtrace attached. Do we really support 3.2 anymore? Maybe we shouldn't? I'm on a gentoo system. I don't know wha ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470 From noreply at sourceforge.net Thu Apr 13 21:26:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 12:26:55 -0700 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 19:29 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:54 Message: Logged In: YES user_id=413 modifying bsddb/__init__.py to wrap all calls with DeadlockWrap will be a bit of a pita (but would be doable). I've attached an example wrapped_hammer.py that demonstrates the _openDBEnv change as well as DeadlockWrap wrapping to work properly. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:31 Message: Logged In: YES user_id=413 oh good i see you already suggested the simple thread calling lock_detect that I was about to suggest. :) regardless a thread isn't needed. see dbenv.set_lk_detect which tells BerkeleyDB to run deadlock detection automatically anytime a lock conflict occurs. http://www.sleepycat.com/docs/api_c/env_set_lk_detect.html Just add e.set_lk_detect(db.DB_LOCK_DEFAULT) to bsddb/__init__.py's _openDBEnv() function. That causes hammer.py to get DBLockDeadlockError exceptions as expected (dying if the main thread gets one). No lock_detect thread needed. The bsddb legacy interface in __init__.py could have all of its database accesses wrapped in the bsddb.dbutils.DeadlockWrap function. to prevent this. (testing now) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 20:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 18:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-05 18:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 12:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 10:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 09:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 07:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 00:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 00:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 23:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-27 22:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 16:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 11:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 15:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 12:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 12:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 12:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 11:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 10:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 09:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 09:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 16:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 01:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Thu Apr 13 21:36:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 12:36:06 -0700 Subject: [ python-Bugs-1466301 ] ImportError: Module _subprocess not found Message-ID: Bugs item #1466301, was opened at 2006-04-07 14:41 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 Please note that this 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: 3rd Party >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Africanis (africanis) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: Module _subprocess not found Initial Comment: I'm using Enthought Python 2.3.5 together with IPython and matplotlib on Windows XP SP2. I had problems importing pylab (in order actually to use matplotlib) until I changed the attached file (see from line 365). I have absolutely no idea what effect this will have on other modules (I'm fairly new to programming), but matplotlib seems to work okay now. Ignorance is bliss... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 13:21 Message: Logged In: YES user_id=21627 Thanks for the patch. I'm not quite sure what you have been doing: Python 2.3.5 did not include the subprocess module at all. So if you got it either from IPython or from Enthought Python, you could report the problem to them. They should either include _subprocess.pyd (as it was released with Python 2.4), or enable the if 0 block, meant for pywin32, or drop subprocess entirely. In any case, this should be a problem for Python 2.4 or (the upcoming) Python 2.5. Closing it as a third-party bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&group_id=5470 From noreply at sourceforge.net Thu Apr 13 22:03:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 13:03:28 -0700 Subject: [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific addressing Message-ID: Bugs item #764437, was opened at 2003-07-02 07:13 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: AF_UNIX sockets do not handle Linux-specific addressing Initial Comment: As described in unix(7) manpage, Linux allows for special "kernel namespace" AF_UNIX sockets defined. With such sockets, the first byte of the path is \x00, and the rest is the address. These sockets do not show up in the filesystem. socketmodule.c:makesockaddr (as called by recvfrom) uses code like PyString_FromString(a->sun_path) to retrieve the address. This is incorrect -- on Linux, if the first byte of a->sun_path is null, the function should use PyString_FromStringAndSize to retrieve the full 108- byte buffer. I am not entirely sure that this is the only thing that needs to be fixed, but bind() and sendto() work with these sort of socket paths just fine. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-04-13 20:03 Message: Logged In: YES user_id=4771 I'm about to check in a slightly different patch (also at 1062014) which tries to preserve the length of the abstract namespace addresses (the kernel saves this length even though it is not zero-terminated, so that the names '\x00abc' and '\x00abc\x00' and '\x00abc\x00\x00' are all different in theory). The patch no longer exposes UNIX_PATH_MAX because I'm not sure it's useful any more. If anyone who is relying on this Linux extension more than myself has comments, now would be a good time :-) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-08 11:03 Message: Logged In: YES user_id=129426 Patch is at 1062014 The comments below state that UNIX_PATH_MAX is defined in sys/un.h, but it isn't. The patch gets it in another (hopefully portable) way (and also exposes it as a new constant in the socket module) ---------------------------------------------------------------------- Comment By: Aaron Brady (insomnike) Date: 2004-07-07 14:39 Message: Logged In: YES user_id=1057404 It should use UNIX_PATH_MAX, but it should also check that the length of the buffer supplied is correct, my bad. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2004-07-07 14:37 Message: Logged In: YES user_id=595126 """The socket?s address in this namespace is given by the rest of the bytes in sun_path. Note that names in the abstract namespace are not zero‐terminated.""" The length would be UNIX_PATH_MAX in this case. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 14:04 Message: Logged In: YES user_id=11375 Should it use UNIX_PATH_MAX as the length of the string, or 1+ strlen(a->sun_path+1)? (The leading null byte, plus the following null-terminated string?) ---------------------------------------------------------------------- Comment By: Aaron Brady (insomnike) Date: 2004-06-05 19:16 Message: Logged In: YES user_id=1057404 Also checks for "linux" to be defined, on Mondragon's recommendation. ### --- socketmodule.c 3 Jun 2004 09:24:42 -0000 1.291 +++ socketmodule.c 5 Jun 2004 18:17:51 -0000 @@ -942,6 +942,11 @@ case AF_UNIX: { struct sockaddr_un *a = (struct sockaddr_un *) addr; +#if defined(UNIX_PATH_MAX) && defined(linux) + if (*a->sun_path == 0) { + return PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX); + } +#endif /* UNIX_PATH_MAX && linux */ return PyString_FromString(a->sun_path); } #endif /* AF_UNIX */ ### ---------------------------------------------------------------------- Comment By: Aaron Brady (insomnike) Date: 2004-06-05 19:06 Message: Logged In: YES user_id=1057404 The below patch adds the functionality if UNIX_PATH_MAX is defined (in Linux it's in sys/un.h). ### --- socketmodule.c 3 Jun 2004 09:24:42 -0000 1.291 +++ socketmodule.c 5 Jun 2004 18:08:47 -0000 @@ -942,6 +942,11 @@ case AF_UNIX: { struct sockaddr_un *a = (struct sockaddr_un *) addr; +#if defined(UNIX_PATH_MAX) + if (*a->sun_path == 0) { + return PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX); + } +#endif /* UNIX_PATH_MAX */ return PyString_FromString(a->sun_path); } #endif /* AF_UNIX */ ### ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-25 08:13 Message: Logged In: YES user_id=29957 Eek. What a totally mental design decision on the part of the Linux kernel developers. Is there a magic C preprocessor symbol we can use to detect that this insanity is available? (FWIW, Perl also has problems with this: http://www.alexhudson.com/code/abstract-sockets-and-perl ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 From noreply at sourceforge.net Fri Apr 14 02:51:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 17:51:16 -0700 Subject: [ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9 Message-ID: Bugs item #1460514, was opened at 2006-03-29 01:28 Message generated for change (Comment added) made by dalke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Thomas Heller (theller) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. ---------------------------------------------------------------------- >Comment By: Andrew Dalke (dalke) Date: 2006-04-13 18:51 Message: Logged In: YES user_id=190903 Sorry - was ill and not doing anything for a week. I've built the latest code from SVN. No problems with the compilation and I am able to import just fine. I did get the following compiler warnings /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c: In function `CField_repr': /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:259: warning: signed size_t format, Py_ssize_t arg (arg 3) /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:267: warning: signed size_t format, Py_ssize_t arg (arg 3) /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:383: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:384: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:388: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:389: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:394: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c: In function `ffi_closure_helper_DARWIN': /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:622: warning: unused variable `temp_ld' When I run the self test I get one error FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_ctypes.py", line 12, in test_main() File "Lib/test/test_ctypes.py", line 9, in test_main run_suite(unittest.TestSuite(suites)) File "/Users/dalke/cvses/python-svn/Lib/test/test_support.py", line 285, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/Users/dalke/cvses/python-svn/Lib/ctypes/test/test_loading.py", line 30, in test_load cdll.load(libc_name) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 153, in _load return self.load_library(pathname, mode) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/Users/dalke/cvses/python-svn/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlcompat: unable to open this file with RTLD_LOCAL which is probably ignorable - OS X has its own sense of what shared libraries do. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-03 14:18 Message: Logged In: YES user_id=11105 As a temporary fix, I removed the '+live_support' attribute in the source file. Andrew, can you please verify that this works for you? Thanks, Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 From noreply at sourceforge.net Fri Apr 14 05:35:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Apr 2006 20:35:33 -0700 Subject: [ python-Bugs-1470212 ] mailbox.PortableUnixMailbox fails to parse 'From ' in body Message-ID: Bugs item #1470212, was opened at 2006-04-14 03: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=1470212&group_id=5470 Please note that this 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 Submitted By: Lars Kellogg-Stedman (larsks) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.PortableUnixMailbox fails to parse 'From ' in body Initial Comment: I have a Unix mailbox file that contains the following text in the body of a message: ---[ cut here ]--- EFCO also offers casements with integral blinds. See:=20 http://www.efcocorp.com/public/earm/products/default.asp?j=3D1&P=3D43&L=3D= 1=20 >From that page, select select "Features and Benefits" from under the heading "Product Overview"=20 ---[ cut here ]--- mailbox.PortableUnixMailbox erroneously interprets the "From" at the beginning of the line as the beginning of a new message. Since 'From ' is only a valid header at the beginning of a message, perhaps the module could look at the following line and see if it looks like an RFC2822 header before accepting 'From ' as a message delimiter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 From noreply at sourceforge.net Fri Apr 14 09:19:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 00:19:56 -0700 Subject: [ python-Bugs-1469629 ] __dict__ = self in subclass of dict causes a memory leak? Message-ID: Bugs item #1469629, was opened at 2006-04-12 22:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) Summary: __dict__ = self in subclass of dict causes a memory leak? Initial Comment: Using: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 For reasons I do not understand, the following class leaks itself continuously: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) self.__dict__ = self Whereas this version does not: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) def __getattr__(self, key): return self[key] def __setattr__(self, key, value): self[key] = value My test looks like this: for n in xrange(1000000): import gc gc.collect() ad = AttrDict() ad['x'] = n ad.y = ad.x print n, ad.x, ad.y And I sit and watch in the windows task manager while the process grows and grows. With the __getattr__ version, it doesn't grow. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-14 00:19 Message: Logged In: YES user_id=33168 Armin, why not just check any leaking test cases into Lib/test/leakers? I have no idea if your patch is correct or not. I wouldn't be surprised if there are a bunch more issues similar to this. What if you stick self in self.__dict__ (I'm guessing this is ok, but there are a bunch of variations) or start playing with weakrefs? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-13 02:58 Message: Logged In: YES user_id=4771 This is caused by the tp_clear not doing its job -- in this case, tp_clear is subtype_clear(), which does not reset the __dict__ slot to NULL because it assumes that the __dict__ slot's content itself will be cleared, which is perfectly true but doesn't help if self.__dict__ is self. Attached a patch to fix this. It's kind of hard to test for this bug because all instances of AttrDict are really cleared, weakrefs to them are removed, etc. Also attached is an example showing a similar bug: a cycle through the ob_type field, with a object U whose class is itself. It is harder to clear this link because we cannot just set ob_type to NULL in subtype_clear. Ideas welcome... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 From noreply at sourceforge.net Fri Apr 14 10:30:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 01:30:13 -0700 Subject: [ python-Bugs-1470212 ] mailbox.PortableUnixMailbox fails to parse 'From ' in body Message-ID: Bugs item #1470212, was opened at 2006-04-13 20:35 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 Please note that this 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 Submitted By: Lars Kellogg-Stedman (larsks) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.PortableUnixMailbox fails to parse 'From ' in body Initial Comment: I have a Unix mailbox file that contains the following text in the body of a message: ---[ cut here ]--- EFCO also offers casements with integral blinds. See:=20 http://www.efcocorp.com/public/earm/products/default.asp?j=3D1&P=3D43&L=3D= 1=20 >From that page, select select "Features and Benefits" from under the heading "Product Overview"=20 ---[ cut here ]--- mailbox.PortableUnixMailbox erroneously interprets the "From" at the beginning of the line as the beginning of a new message. Since 'From ' is only a valid header at the beginning of a message, perhaps the module could look at the following line and see if it looks like an RFC2822 header before accepting 'From ' as a message delimiter. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 01:30 Message: Logged In: YES user_id=1185570 Use rfc822.py in lieu of mailbox to first parse the message into an rfc822.Message... then pass it to the Mailbox.PortableUnixMailbox constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 From noreply at sourceforge.net Fri Apr 14 10:33:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 01:33:19 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 12:39 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 Please note that this 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 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 01:33 Message: Logged In: YES user_id=1185570 It looks as though it's a feature... The first %s will print the whole dictionary as a string, the second, only that value looked up by the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Fri Apr 14 12:04:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 03:04:04 -0700 Subject: [ python-Bugs-1470300 ] QNX4.25 port Message-ID: Bugs item #1470300, was opened at 2006-04-14 18: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=1470300&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: QNX4.25 port Initial Comment: In QNX4.25 there is no and rusage. I used next patch to compile _hotshot.c module in QNX4.25 wuth Watcom10.6 compiler. *** /usr/local/src/Python-2.4.3.orig/Modules/_hotshot.c Mon Mar 20 16:37:16 2006 --- /usr/local/src/Python-2.4.3/Modules/_hotshot.c Sat Apr 15 17:16:47 2006 *************** *** 26,32 **** #ifndef HAVE_GETTIMEOFDAY #error "This module requires gettimeofday() on non- Windows platforms!" #endif ! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) #include #else #include --- 26,32 ---- #ifndef HAVE_GETTIMEOFDAY #error "This module requires gettimeofday() on non- Windows platforms!" #endif ! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) || defined(__QNX__) #include #else #include *************** *** 917,923 **** #endif } #if defined(MS_WINDOWS) || defined(PYOS_OS2) || \ ! defined(__VMS) rusage_diff = -1; #else { --- 917,923 ---- #endif } #if defined(MS_WINDOWS) || defined(PYOS_OS2) || \ ! defined(__VMS) || defined (__QNX__) rusage_diff = -1; #else { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470 From noreply at sourceforge.net Fri Apr 14 12:06:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 03:06:40 -0700 Subject: [ python-Bugs-1470300 ] QNX4.25 port Message-ID: Bugs item #1470300, was opened at 2006-04-14 18:04 Message generated for change (Comment added) made by kbob_ru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: QNX4.25 port Initial Comment: In QNX4.25 there is no and rusage. I used next patch to compile _hotshot.c module in QNX4.25 wuth Watcom10.6 compiler. *** /usr/local/src/Python-2.4.3.orig/Modules/_hotshot.c Mon Mar 20 16:37:16 2006 --- /usr/local/src/Python-2.4.3/Modules/_hotshot.c Sat Apr 15 17:16:47 2006 *************** *** 26,32 **** #ifndef HAVE_GETTIMEOFDAY #error "This module requires gettimeofday() on non- Windows platforms!" #endif ! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) #include #else #include --- 26,32 ---- #ifndef HAVE_GETTIMEOFDAY #error "This module requires gettimeofday() on non- Windows platforms!" #endif ! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) || defined(__QNX__) #include #else #include *************** *** 917,923 **** #endif } #if defined(MS_WINDOWS) || defined(PYOS_OS2) || \ ! defined(__VMS) rusage_diff = -1; #else { --- 917,923 ---- #endif } #if defined(MS_WINDOWS) || defined(PYOS_OS2) || \ ! defined(__VMS) || defined (__QNX__) rusage_diff = -1; #else { ---------------------------------------------------------------------- >Comment By: kbob_ru (kbob_ru) Date: 2006-04-14 18:06 Message: Logged In: YES user_id=1347065 patch in attachment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470 From noreply at sourceforge.net Fri Apr 14 15:11:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 06:11:34 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 23:11 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=1470353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Fri Apr 14 17:04:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 08:04:29 -0700 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 14:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-14 17:04 Message: Logged In: YES user_id=21627 This was fixed with patch #1355971. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-16 22:49 Message: Logged In: YES user_id=1188172 Is that still an issue? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:58 Message: Logged In: YES user_id=315535 Fix for part 1 here: http://sourceforge.net/tracker/index.php?func=detail&aid=1355971&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:45 Message: Logged In: YES user_id=315535 Already on it :) Shall have a patch up shortly. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 17:44 Message: Logged In: YES user_id=44345 I was thinking it might be something like that. Perhaps asdl_c.py should be modified to accept an output flag (--output=[hc] or -h/-c) so it only generates one file or the other. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Fri Apr 14 17:08:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 08:08:14 -0700 Subject: [ python-Bugs-1470300 ] QNX4.25 port Message-ID: Bugs item #1470300, was opened at 2006-04-14 12:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: QNX4.25 port Initial Comment: In QNX4.25 there is no and rusage. I used next patch to compile _hotshot.c module in QNX4.25 wuth Watcom10.6 compiler. *** /usr/local/src/Python-2.4.3.orig/Modules/_hotshot.c Mon Mar 20 16:37:16 2006 --- /usr/local/src/Python-2.4.3/Modules/_hotshot.c Sat Apr 15 17:16:47 2006 *************** *** 26,32 **** #ifndef HAVE_GETTIMEOFDAY #error "This module requires gettimeofday() on non- Windows platforms!" #endif ! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) #include #else #include --- 26,32 ---- #ifndef HAVE_GETTIMEOFDAY #error "This module requires gettimeofday() on non- Windows platforms!" #endif ! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) || defined(__QNX__) #include #else #include *************** *** 917,923 **** #endif } #if defined(MS_WINDOWS) || defined(PYOS_OS2) || \ ! defined(__VMS) rusage_diff = -1; #else { --- 917,923 ---- #endif } #if defined(MS_WINDOWS) || defined(PYOS_OS2) || \ ! defined(__VMS) || defined (__QNX__) rusage_diff = -1; #else { ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-14 17:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r45391. ---------------------------------------------------------------------- Comment By: kbob_ru (kbob_ru) Date: 2006-04-14 12:06 Message: Logged In: YES user_id=1347065 patch in attachment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470 From noreply at sourceforge.net Fri Apr 14 17:48:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 08:48:48 -0700 Subject: [ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers Message-ID: Bugs item #1470422, was opened at 2006-04-14 11: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=1470422&group_id=5470 Please note that this 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 Submitted By: Michael Tsai (michaeltsai) Assigned to: Nobody/Anonymous (nobody) Summary: Logging doesn't report the correct filename or line numbers Initial Comment: I have a logger that prints out %(filename)s:%(lineno)d along with the message. Instead of printing the file and line in my code where I call the logger, it prints out a location in logging/__init__.py. I was able to fix this, at least for my purposes, by changing logging.currentframe from sys._getframe to lambda:sys._getframe(3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 From noreply at sourceforge.net Fri Apr 14 20:35:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 11:35:17 -0700 Subject: [ python-Bugs-1162001 ] configure incorrectly adds -OPT:Olimit=0 for icc Message-ID: Bugs item #1162001, was opened at 2005-03-12 14:54 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 Please note that this 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: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: configure incorrectly adds -OPT:Olimit=0 for icc Initial Comment: When using Python 2.4 and the Intel C Compiler, configure adds -OPT:Olimit=0 to BASECFLAGS. This is because using icc -OPT:Olimit=0 does not produce an error, but instead an irritating warning for every source file compiled. $ icc -OPT:Olimit=0 test1.c; echo $? icc: Command line warning: ignoring option '-O'; no argument required 0 $ gcc -OPT:Olimit=0 test1.c; echo $? cc1: error: invalid option argument `-OPT:Olimit=0' 1 ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-04-14 18:35 Message: Logged In: YES user_id=987664 Supposedly fixed in r41953. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-12 15:58 Message: Logged In: YES user_id=987664 Patch submitted: http://sourceforge.net/tracker/index.php?func=detail&aid=1162023&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 From noreply at sourceforge.net Fri Apr 14 20:36:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 11:36:14 -0700 Subject: [ python-Bugs-1162001 ] configure incorrectly adds -OPT:Olimit=0 for icc Message-ID: Bugs item #1162001, was opened at 2005-03-12 14:54 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 Please note that this 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: Platform-specific Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: configure incorrectly adds -OPT:Olimit=0 for icc Initial Comment: When using Python 2.4 and the Intel C Compiler, configure adds -OPT:Olimit=0 to BASECFLAGS. This is because using icc -OPT:Olimit=0 does not produce an error, but instead an irritating warning for every source file compiled. $ icc -OPT:Olimit=0 test1.c; echo $? icc: Command line warning: ignoring option '-O'; no argument required 0 $ gcc -OPT:Olimit=0 test1.c; echo $? cc1: error: invalid option argument `-OPT:Olimit=0' 1 ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-04-14 18:36 Message: Logged In: YES user_id=987664 Supposedly fixed in r41953. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2006-04-14 18:35 Message: Logged In: YES user_id=987664 Supposedly fixed in r41953. ---------------------------------------------------------------------- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-12 15:58 Message: Logged In: YES user_id=987664 Patch submitted: http://sourceforge.net/tracker/index.php?func=detail&aid=1162023&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 From noreply at sourceforge.net Fri Apr 14 21:08:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 12:08:16 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Fri Apr 14 21:09:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 12:09:12 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-14 21:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Fri Apr 14 21:24:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 12:24:32 -0700 Subject: [ python-Bugs-1470502 ] Mention coercion removal in Misc/NEWS Message-ID: Bugs item #1470502, was opened at 2006-04-14 12: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=1470502&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Mention coercion removal in Misc/NEWS Initial Comment: Neal has been ripping out __coerce__ but Misc/NEWS doesn't mention that. Should be mentioned (along with test_coercion being removed). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470502&group_id=5470 From noreply at sourceforge.net Fri Apr 14 21:31:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 12:31:55 -0700 Subject: [ python-Bugs-1470508 ] Error in PyGen_NeedsFinalizing() Message-ID: Bugs item #1470508, was opened at 2006-04-14 15:31 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=1470508&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) Assigned to: Phillip J. Eby (pje) Summary: Error in PyGen_NeedsFinalizing() Initial Comment: There's an off-by-one error in PyGen_NeedsFinalizing(): the loop starts by looking at f->f_blockstack[f->f_iblock], but that's one beyond the largest legitimate f_blockstack index. As a result, any generator with an active loop is very likely to claim it needs finalizing (to the extent that it's unlikely that reading up trash for b_type will match SETUP_LOOP). The attached patch repairs that, but also tries to remove some of the goofy .close() gimmicks added to old tests in test_generators to worm around "leaks" caused by that all generators said they needed finalizers in 2.5 at first. (That's how I bumped into this: I tried removing the .close() gimmicks first, but -R:: runs said they still leaked -- that started the trail leading to PyGen_NeedsFinalizing()). Alas, after applying the patch, test_generators craps out in a debug build with a NULL-pointer dereference in _Py_ForgetReference(), in the guts of the `if` test deciding whether to produce an "UNREF invalid object" error. At the time, op_type is _PyGen_Type and op->_ob_next = _ob_prev = NULL, probably meaning that op was already passed to _Py_ForgetReference() previously. We get into _Py_ForgetReference() via a chain starting at the the decref in ceval.c's while (STACK_LEVEL() > b->b_level) { v = POP(); Py_XDECREF(v); and we got into PyEval_EvalFrameEx via gen_send_ex via gen_close via gen_dealloc via (eventually) a dict on some instance going away ... and then I got lost. Looks like there are several more layers of generator deallocs on the call stack too. I'm out of time for looking at this now, so recording it here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470 From noreply at sourceforge.net Fri Apr 14 22:07:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 13:07:46 -0700 Subject: [ python-Bugs-1470540 ] XMLGenerator creates a mess with UTF-16 Message-ID: Bugs item #1470540, was opened at 2006-04-15 00:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nikolai Grigoriev (ngrig) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator creates a mess with UTF-16 Initial Comment: When output encoding in xml.sax.saxutils.XMLGenerator is set to UTF-16, the result is a terrible mess. Namely: - it does not encode the XML declaration at the very top of the file (leaving it in single-byte Latin); - it leaves closing '>' of each start tag unencoded (that is, always outputs a single byte); - it inserts a spurious byte order mark for each tag, each attribute, each text node, and each processing instruction. A test illustrating the issue is attached. The issue is applicable to both stable (2.4.3) and current (2.5) versions of Python. --------------------------------------------- Looking in xml/sax/saxutils.py, I see the problem in XMLGenerator._write(): - one-byte strings aren't recoded at all (sic!); - two-byte strings are converted using unicode.encode(); this results in a BOM for each call of _write() on Unicode strings. The issue is easy to fix by using StreamWriter instead of a plain stream as the output sink. I am going to submit a patch shortly. Regards, Nikolai Grigoriev ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 From noreply at sourceforge.net Fri Apr 14 22:09:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 13:09:06 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Sat Apr 15 01:22:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 16:22:05 -0700 Subject: [ python-Bugs-1470508 ] Error in PyGen_NeedsFinalizing() Message-ID: Bugs item #1470508, was opened at 2006-04-14 21:31 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) Assigned to: Phillip J. Eby (pje) Summary: Error in PyGen_NeedsFinalizing() Initial Comment: There's an off-by-one error in PyGen_NeedsFinalizing(): the loop starts by looking at f->f_blockstack[f->f_iblock], but that's one beyond the largest legitimate f_blockstack index. As a result, any generator with an active loop is very likely to claim it needs finalizing (to the extent that it's unlikely that reading up trash for b_type will match SETUP_LOOP). The attached patch repairs that, but also tries to remove some of the goofy .close() gimmicks added to old tests in test_generators to worm around "leaks" caused by that all generators said they needed finalizers in 2.5 at first. (That's how I bumped into this: I tried removing the .close() gimmicks first, but -R:: runs said they still leaked -- that started the trail leading to PyGen_NeedsFinalizing()). Alas, after applying the patch, test_generators craps out in a debug build with a NULL-pointer dereference in _Py_ForgetReference(), in the guts of the `if` test deciding whether to produce an "UNREF invalid object" error. At the time, op_type is _PyGen_Type and op->_ob_next = _ob_prev = NULL, probably meaning that op was already passed to _Py_ForgetReference() previously. We get into _Py_ForgetReference() via a chain starting at the the decref in ceval.c's while (STACK_LEVEL() > b->b_level) { v = POP(); Py_XDECREF(v); and we got into PyEval_EvalFrameEx via gen_send_ex via gen_close via gen_dealloc via (eventually) a dict on some instance going away ... and then I got lost. Looks like there are several more layers of generator deallocs on the call stack too. I'm out of time for looking at this now, so recording it here. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-15 01:22 Message: Logged In: YES user_id=34209 As explained on python-dev, I believe this patch fixes the crash. It still leaves test_generators leaking 255 references, though, which I find completely unsurprising given the pain it's caused so far :) I do believe these changes are correct even if we don't fix the generator leakage, but someone with more fundamental knowledge of the cyclic GC might want to pronounce. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470 From noreply at sourceforge.net Sat Apr 15 04:28:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Apr 2006 19:28:52 -0700 Subject: [ python-Bugs-1470508 ] Error in PyGen_NeedsFinalizing() Message-ID: Bugs item #1470508, was opened at 2006-04-14 15:31 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Nobody/Anonymous (nobody) Summary: Error in PyGen_NeedsFinalizing() Initial Comment: There's an off-by-one error in PyGen_NeedsFinalizing(): the loop starts by looking at f->f_blockstack[f->f_iblock], but that's one beyond the largest legitimate f_blockstack index. As a result, any generator with an active loop is very likely to claim it needs finalizing (to the extent that it's unlikely that reading up trash for b_type will match SETUP_LOOP). The attached patch repairs that, but also tries to remove some of the goofy .close() gimmicks added to old tests in test_generators to worm around "leaks" caused by that all generators said they needed finalizers in 2.5 at first. (That's how I bumped into this: I tried removing the .close() gimmicks first, but -R:: runs said they still leaked -- that started the trail leading to PyGen_NeedsFinalizing()). Alas, after applying the patch, test_generators craps out in a debug build with a NULL-pointer dereference in _Py_ForgetReference(), in the guts of the `if` test deciding whether to produce an "UNREF invalid object" error. At the time, op_type is _PyGen_Type and op->_ob_next = _ob_prev = NULL, probably meaning that op was already passed to _Py_ForgetReference() previously. We get into _Py_ForgetReference() via a chain starting at the the decref in ceval.c's while (STACK_LEVEL() > b->b_level) { v = POP(); Py_XDECREF(v); and we got into PyEval_EvalFrameEx via gen_send_ex via gen_close via gen_dealloc via (eventually) a dict on some instance going away ... and then I got lost. Looks like there are several more layers of generator deallocs on the call stack too. I'm out of time for looking at this now, so recording it here. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-14 22:28 Message: Logged In: YES user_id=31435 Phillip checked in a related patch that looked good, fixed the segfaults, and allowed to get rid of the explicit closes in the LazyList-based examples without new leaking. (The tee-based examples still need explicit closing to avoid leaking, and I added XXX comments about that.) So, closing as fixed. Thanks! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-04-14 19:22 Message: Logged In: YES user_id=34209 As explained on python-dev, I believe this patch fixes the crash. It still leaves test_generators leaking 255 references, though, which I find completely unsurprising given the pain it's caused so far :) I do believe these changes are correct even if we don't fix the generator leakage, but someone with more fundamental knowledge of the cyclic GC might want to pronounce. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470 From noreply at sourceforge.net Sat Apr 15 09:05:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 00:05:31 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 09:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 13:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 07:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 00:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sat Apr 15 13:18:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 04:18:26 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 23:11 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-15 21:18 Message: Logged In: YES user_id=250749 Your suggested change does indeed get the test to pass on this system. Given the history and relationship of [Free/Net/Open]BSD, I would suggest that for x86 it is very likely that you will need to add defined(__NetBSD__) clauses as well. >From my POV this bug can now be closed. Thanks, Thomas. BTW, the actual patch applied was: --- ffi.c.orig Tue Apr 4 05:26:32 2006 +++ ffi.c Sat Apr 15 21:02:16 2006 @@ -121,7 +121,7 @@ switch (cif->rtype->type) { case FFI_TYPE_VOID: -#if !defined(X86_WIN32) && !defined(__OpenBSD__) +#if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__FreeBSD__) case FFI_TYPE_STRUCT: #endif case FFI_TYPE_SINT64: @@ -135,7 +135,7 @@ cif->flags = FFI_TYPE_SINT64; break; -#if defined(X86_WIN32) || defined(__OpenBSD__) +#if defined(X86_WIN32) || defined(__OpenBSD__) || defined(__FreeBSD__) case FFI_TYPE_STRUCT: if (cif->rtype->size == 1) { ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-15 05:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-15 05:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Sat Apr 15 16:48:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 07:48:16 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by atler_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 16:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 09:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 13:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 07:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 00:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sat Apr 15 17:30:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 08:30:17 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 17:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 16:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 09:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 13:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 07:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 00:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Sat Apr 15 19:27:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 10:27:41 -0700 Subject: [ python-Bugs-1448934 ] urllib2+https+proxy not working Message-ID: Bugs item #1448934, was opened at 2006-03-13 15:55 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448934&group_id=5470 Please note that this 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 Submitted By: Rui Martins (ruibmartins) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2+https+proxy not working Initial Comment: Using urllib2 to access an https site using a proxy doesn't work. It always returns " " I've been looking around for bug reports on this and code samples, but all that I've got were emails/forum posts dating back to 2003 warning that the HTTPS over Proxy in urllib2 isn't implemented in Python! Is this true? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:27 Message: Logged In: YES user_id=261020 Yes, there is no special support for using https proxies (via the CONNECT method) in httplib or urllib2. http://python.org/sf/515003 shows how to do it, but the patch is not good enough to be added to the standard library. Feel free to write a better patch! Please close this, since it's really a feature request, not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448934&group_id=5470 From noreply at sourceforge.net Sat Apr 15 19:34:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 10:34:19 -0700 Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2 Message-ID: Bugs item #944394, was opened at 2004-04-29 12:02 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this 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 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-06-01 09:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-05-31 22:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 From noreply at sourceforge.net Sat Apr 15 19:59:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 10:59:50 -0700 Subject: [ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr Message-ID: Bugs item #900898, was opened at 2004-02-20 06:51 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: James Kruth (jk7) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr Initial Comment: If the Request object being used returns a URI with a port included (e.g. http://www.mysite.com:7777/index.html) If Request.get_full_url() or Request.get_host() returns a URI or host with a port included (e.g. http://www.mysite.com:7777/index.html or www.mysite.com:7777, respectively), and authentication (proxy or http, basic only) is required, then the respective AuthHandlers (HTTPBasicAuthHandler, ProxyBasicAuthHandler) end up calling http_error_auth_reqed with a host looking like "www.mysite.com:7777". http_error_auth_reqed then precedes to call retry_http_basic_auth with the same host parameter, which in turn calls HTTPPasswordMgr.find_user_password. The problem is that find_user_password appears to expect a full URI, and attempts to reduce it to just a host, by calling reduce_uri. If a bare host with a port is passed (like "www.mysite.com:7777"), then reduce_uri returns just the port number in the netloc position - which find_user_password then attempts to compare against the correct host name you've stored in your HTTPPasswordMgr object along with your user name and password. I believe either find_user_password should not reduce the host, or the Auth Handler objects should pass full hostnames to find_user_password. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:59 Message: Logged In: YES user_id=261020 This is fixed by patch 1470846, which includes tests and doc fix / update (though I neglected to mention that the patch fixes this problem in the initial patch comment; I'll rectify that now). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2004-04-06 20:58 Message: Logged In: YES user_id=4631 I ran into this problem today with Python 2.3.3 on RedHat 9. I'm using port numbers in my URLs, and I found that the Auth Handler did NOT correctly find the userid and password registered. ie: authinfo = urllib2.HTTPPasswordMgrWithDefaultRealm() authinfo.add_password(None, host, userid, password) authHandler = urllib2.HTTPBasicAuthHandler(authinfo) opener = urllib2.build_opener(authHandler) where host = "http://localhost:7993" I've tested the proposed fix shown in urllib2_bug.py at line 31, to whit, this: class HTTPBasicAuthHandlerF(AbstractBasicAuthHandler, BaseHandler): auth_header = 'Authorization' def http_error_401(self, req, fp, code, msg, headers): host = req.get_full_url() return self.http_error_auth_reqed('www-authenticate', host, req, headers) This appears to have corrected the problem. test_urllib2.py and test_urllib.py both pass after making this change. I did not test the ProxyBasicAuthHandler change (I don't have a proxy) ---------------------------------------------------------------------- Comment By: James Kruth (jk7) Date: 2004-02-20 21:25 Message: Logged In: YES user_id=979977 Here's a sample of the problem... ---------------------------------------------------------------------- Comment By: James Kruth (jk7) Date: 2004-02-20 14:39 Message: Logged In: YES user_id=979977 I've made up a file with some source code and comments that will hopefully clarify what I posted. I will post an example of the problem a bit later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470 From noreply at sourceforge.net Sat Apr 15 20:07:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 11:07:11 -0700 Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2 Message-ID: Bugs item #944394, was opened at 2004-04-29 11:02 Message generated for change (Comment added) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this 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 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2006-04-15 18:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 17:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-06-01 08:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-05-31 21:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 From noreply at sourceforge.net Sat Apr 15 20:45:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 11:45:29 -0700 Subject: [ python-Bugs-680577 ] urllib2 authentication problem Message-ID: Bugs item #680577, was opened at 2003-02-05 00:22 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: GaryD (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication problem Initial Comment: I've found a problem using the authentication in urllib2. When matching up host-names in order to find a password, then putting the protocol in the address makes it seem like a different address. eg... I create a HTTPBasicAuthHandler with a HTTPPasswordMgrWithDefaultRealm, and add the tuple (None, "http://proxy.blah.com:17828", "foo", "bar") to it. I then setup the proxy to use http://proxy.blah.com:17828 (which requires authentication). When I connect, the password lookup fails, because it is trying to find a match for "proxy.blah.com:17828" rather than "http://proxy.blah.com:17828" This problem doesn't exist if I pass "proxy.blah.com:17828" to the password manager. There seems to be some stuff in HTTPPasswordMgr to deal with variations on site names, but I guess it's not working in this case (unless this is intentional). Version Info: Python 2.2 (#1, Feb 24 2002, 16:21:58) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 19:45 Message: Logged In: YES user_id=261020 This issue is fixed by patch 1470846. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-16 12:49 Message: Logged In: YES user_id=261020 Thanks! It seems .reduce_uri() tries to cope with hostnames as well as absoluteURIs. I don't understand why it wants to do that, but it fails, because it doesn't anticipate what urlparse does when a port is present: >>> urlparse.urlparse("foo.bar.com") ('', '', 'foo.bar.com', '', '', '') >>> urlparse.urlparse("foo.bar.com:80") ('foo.bar.com', '', '80', '', '', '') I haven't checked, but I assume it's just incorrect use of urlparse to pass it a hostname. Of course, if it's "fixed" to only accept absoluteURIs, it will break existing code, so I guess it must be fixed for hostnames. :-(( Also, I think .is_suburi("/foo/spam", "/foo/eggs") should return False, but returns True, and .http_error_40x() use req.get_host() when they should be using req.get_full_url() (from a quick look at RFC 2617). ---------------------------------------------------------------------- Comment By: GaryD (gazzadee) Date: 2003-12-16 03:10 Message: Logged In: YES user_id=693152 Okay, I have attached a file that replicates this problem. If you run it as is (replacing the proxy name and address with something suitable), then it will fail (requiring proxy authentication). If you uncomment line 23 (which specifies the password without the scheme), then it will work successfully. Technical Info: * For a proxy, I am using Squid Cache version 2.4.STABLE7 for i586-mandrake-linux-gnu... * I have replicated the problem with Python 2.2.2 on Linux, and Python 2.3.2 on Windows XP. ---------------------------------------------------------------------- Comment By: GaryD (gazzadee) Date: 2003-12-16 02:08 Message: Logged In: YES user_id=693152 This was a while ago, and my memory has faded. I'll try to respond intelligently. I think the question was with the way the password manager looks up passwords, rather than anything else. I am pretty sure that the problem is not to do with the URI passed to urlopen(). In the code shown below, the problem was solely dependent on whether I added the line: (None, "blah.com:17828", "foo", "bar") ...to the HTTPPasswordMgrWithDefaultRealm object. If that password set was added, then the password lookup for the proxy was successful, and urlopen() worked. If that password set was not included, then the password lookup for the proxy was unsuccessful (despite the inclusion of the other 2, similar, password sets - "http://blah.com:17828" and "blah.com"), and urlopen() would fail. Hence my suspicion that the password manager did not fully remove the scheme, despite attempts to do so. I'll see if I can set it up on the latest python and get it to happen again. Just as an explanation, the situation was that I was running an authenticating proxy on a non-standard port (in order to avoid clashing with the normal proxy), in order to test out how my download code would work through an authenticating proxy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-01 00:14 Message: Logged In: YES user_id=261020 The problem seems to be with the port (:17828), not the URL scheme (http:), because HTTPPasswordMgr.reduce_uri() removes the scheme. RFC 2617 (top of page 3) says nothing about removing the port from the URI. urllib2 does not remove the port, so this doesn't appear to be a bug. I guess gazzadee was doing a urlopen with a different canonical root URI (RFC 2617, top of page 3 again) to the one he gave in add_password (ie. the URL he passed to urlopen() had no explicit port number). ---------------------------------------------------------------------- Comment By: GaryD (gazzadee) Date: 2003-02-09 23:17 Message: Logged In: YES user_id=693152 Okay, the same problem crops up in Python 2.2.2 running under cygwin on Win XP Version Info: Python 2.2.2 (#1, Dec 31 2002, 12:24:34) [GCC 3.2 20020927 (prerelease)] on cygwin Here's the pertinent section of my test file (passwords and URL changed to protect the innocent): # Setup proxy proxy_handler = ProxyHandler({"http" : "http://blah.com:17828"}) # Setup authentication pass_mgr = HTTPPasswordMgrWithDefaultRealm() for passwd in [ \ (None, "http://blah.com:17828", "foo", "bar"), \ # (None, "blah.com:17828", "foo", "bar"), \ # Works if this line is uncommented (None, "blah.com", "foo", "bar"), \ ]: print("Adding password set (%s, %s, %s, %s)" % passwd) pass_mgr.add_password(*passwd) auth_handler = HTTPBasicAuthHandler(pass_mgr) proxy_auth_handler = ProxyBasicAuthHandler(pass_mgr) # Now build a new URL opener and install it opener = build_opener(proxy_handler, proxy_auth_handler, auth_handler, HTTPHandler) install_opener(opener) # Now try to open a file and see what happens request = Request("http://www.google.com") try: remotefile = urlopen(request) except HTTPError, ex: print("Unable to download file due to HTTP Error %d (%s)." % (ex.code, ex.msg)) return ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-02-07 23:21 Message: Logged In: YES user_id=163326 Can you please retry with Python 2.2.2? It seems that a related bug was fixed for 2.2.2: http://python.org/2.2.2/NEWS.txt has an entry: """ - In urllib2.py: fix proxy config with user+pass authentication. [SF patch 527518] """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 From noreply at sourceforge.net Sat Apr 15 20:49:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 11:49:15 -0700 Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2 Message-ID: Bugs item #944394, was opened at 2004-04-29 12:02 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this 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 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 19:49 Message: Logged In: YES user_id=261020 They are here: http://docs.python.org/lib/urllib2-examples.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-04-15 19:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-06-01 09:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-05-31 22:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 From noreply at sourceforge.net Sat Apr 15 22:06:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 13:06:21 -0700 Subject: [ python-Bugs-1281692 ] urllib violates rfc 959 Message-ID: Bugs item #1281692, was opened at 2005-09-04 18:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 21:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1357260 reports the same issue for both urllib and urllib2. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-08 07:18 Message: Logged In: YES user_id=341410 "The pathname should specify a directory or other system-specific file group descriptor." If the system (ftp server) does not support a particular 'file name' as a 'file group descriptor', it seems to me that the system (ftp server) is braindead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 From noreply at sourceforge.net Sat Apr 15 22:06:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 13:06:25 -0700 Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable. Message-ID: Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this 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 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 21:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1281692 reports the same issue for the urllib case, and includes a reference to the RFC. ---------------------------------------------------------------------- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-17 05:38 Message: Logged In: YES user_id=1033842 File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd return self.getresp() File "/usr/lib/python2.4/ftplib.py", line 216, in getresp raise error_perm, resp IOError: [Errno ftp error] [Errno ftp error] 550 tompda_685692_Professional.Palm.OS.Programming.part12.rar: No such file or directory. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 13:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? ---------------------------------------------------------------------- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 From noreply at sourceforge.net Sat Apr 15 22:26:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 13:26:40 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-15 22:26 Message: Logged In: YES user_id=11105 Committed as 45440. For NetBSD, this change seems not to be required - ctypes works fine as it is (I'm testing this on the SF compilefarm host, which has NetBSD 2.0.2). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-15 13:18 Message: Logged In: YES user_id=250749 Your suggested change does indeed get the test to pass on this system. Given the history and relationship of [Free/Net/Open]BSD, I would suggest that for x86 it is very likely that you will need to add defined(__NetBSD__) clauses as well. >From my POV this bug can now be closed. Thanks, Thomas. BTW, the actual patch applied was: --- ffi.c.orig Tue Apr 4 05:26:32 2006 +++ ffi.c Sat Apr 15 21:02:16 2006 @@ -121,7 +121,7 @@ switch (cif->rtype->type) { case FFI_TYPE_VOID: -#if !defined(X86_WIN32) && !defined(__OpenBSD__) +#if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__FreeBSD__) case FFI_TYPE_STRUCT: #endif case FFI_TYPE_SINT64: @@ -135,7 +135,7 @@ cif->flags = FFI_TYPE_SINT64; break; -#if defined(X86_WIN32) || defined(__OpenBSD__) +#if defined(X86_WIN32) || defined(__OpenBSD__) || defined(__FreeBSD__) case FFI_TYPE_STRUCT: if (cif->rtype->size == 1) { ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Sat Apr 15 22:33:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 13:33:46 -0700 Subject: [ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9 Message-ID: Bugs item #1460514, was opened at 2006-03-29 10:28 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Thomas Heller (theller) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-15 22:33 Message: Logged In: YES user_id=11105 Thanks for the feedback. For the warnings in Modules/_ctypes/cfield.c, I have no idea what is wrong there. For the warnings in the libffi-sources I tend to ignore them because I don't want to change them too much. For the test-failure: can you find out why this fails? (In the meantime I'm trying to get hold of 10.3 installation disks - any tips how to shrink the only existing partition on my mac mini running 10.4 and setting up a multi-boot system would be appreciated, if anyone wants to help. As an alternative ssh-access to an existing osx installation for testing would of course also help. I don't know if this is feasible or not ;-) ---------------------------------------------------------------------- Comment By: Andrew Dalke (dalke) Date: 2006-04-14 02:51 Message: Logged In: YES user_id=190903 Sorry - was ill and not doing anything for a week. I've built the latest code from SVN. No problems with the compilation and I am able to import just fine. I did get the following compiler warnings /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c: In function `CField_repr': /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:259: warning: signed size_t format, Py_ssize_t arg (arg 3) /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:267: warning: signed size_t format, Py_ssize_t arg (arg 3) /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:383: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:384: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:388: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:389: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:394: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c: In function `ffi_closure_helper_DARWIN': /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:622: warning: unused variable `temp_ld' When I run the self test I get one error FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_ctypes.py", line 12, in test_main() File "Lib/test/test_ctypes.py", line 9, in test_main run_suite(unittest.TestSuite(suites)) File "/Users/dalke/cvses/python-svn/Lib/test/test_support.py", line 285, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/Users/dalke/cvses/python-svn/Lib/ctypes/test/test_loading.py", line 30, in test_load cdll.load(libc_name) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 153, in _load return self.load_library(pathname, mode) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/Users/dalke/cvses/python-svn/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlcompat: unable to open this file with RTLD_LOCAL which is probably ignorable - OS X has its own sense of what shared libraries do. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-03 22:18 Message: Logged In: YES user_id=11105 As a temporary fix, I removed the '+live_support' attribute in the source file. Andrew, can you please verify that this works for you? Thanks, Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 From noreply at sourceforge.net Sun Apr 16 05:03:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Apr 2006 20:03:22 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 23:11 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-16 13:03 Message: Logged In: YES user_id=250749 In that case, it would be worth confirming whether later versions of FreeBSD (at least 5.4, better 6.0) are also affected. I don't know whether there's anyone from DragonflyBSD active - its a FreeBSD 4.x offshoot. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-16 06:26 Message: Logged In: YES user_id=11105 Committed as 45440. For NetBSD, this change seems not to be required - ctypes works fine as it is (I'm testing this on the SF compilefarm host, which has NetBSD 2.0.2). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-15 21:18 Message: Logged In: YES user_id=250749 Your suggested change does indeed get the test to pass on this system. Given the history and relationship of [Free/Net/Open]BSD, I would suggest that for x86 it is very likely that you will need to add defined(__NetBSD__) clauses as well. >From my POV this bug can now be closed. Thanks, Thomas. BTW, the actual patch applied was: --- ffi.c.orig Tue Apr 4 05:26:32 2006 +++ ffi.c Sat Apr 15 21:02:16 2006 @@ -121,7 +121,7 @@ switch (cif->rtype->type) { case FFI_TYPE_VOID: -#if !defined(X86_WIN32) && !defined(__OpenBSD__) +#if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__FreeBSD__) case FFI_TYPE_STRUCT: #endif case FFI_TYPE_SINT64: @@ -135,7 +135,7 @@ cif->flags = FFI_TYPE_SINT64; break; -#if defined(X86_WIN32) || defined(__OpenBSD__) +#if defined(X86_WIN32) || defined(__OpenBSD__) || defined(__FreeBSD__) case FFI_TYPE_STRUCT: if (cif->rtype->size == 1) { ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-15 05:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-15 05:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Sun Apr 16 09:42:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 00:42:36 -0700 Subject: [ python-Bugs-1470540 ] XMLGenerator creates a mess with UTF-16 Message-ID: Bugs item #1470540, was opened at 2006-04-15 00:07 Message generated for change (Comment added) made by ngrig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nikolai Grigoriev (ngrig) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator creates a mess with UTF-16 Initial Comment: When output encoding in xml.sax.saxutils.XMLGenerator is set to UTF-16, the result is a terrible mess. Namely: - it does not encode the XML declaration at the very top of the file (leaving it in single-byte Latin); - it leaves closing '>' of each start tag unencoded (that is, always outputs a single byte); - it inserts a spurious byte order mark for each tag, each attribute, each text node, and each processing instruction. A test illustrating the issue is attached. The issue is applicable to both stable (2.4.3) and current (2.5) versions of Python. --------------------------------------------- Looking in xml/sax/saxutils.py, I see the problem in XMLGenerator._write(): - one-byte strings aren't recoded at all (sic!); - two-byte strings are converted using unicode.encode(); this results in a BOM for each call of _write() on Unicode strings. The issue is easy to fix by using StreamWriter instead of a plain stream as the output sink. I am going to submit a patch shortly. Regards, Nikolai Grigoriev ---------------------------------------------------------------------- >Comment By: Nikolai Grigoriev (ngrig) Date: 2006-04-16 11:42 Message: Logged In: YES user_id=195108 FYI: I posted a patch (#1470548) that fixes the issue. Regards, Nikolai Grigoriev ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 From noreply at sourceforge.net Sun Apr 16 12:16:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 03:16:09 -0700 Subject: [ python-Bugs-1471243 ] Visual Studio 2005 CRT error handler Message-ID: Bugs item #1471243, was opened at 2006-04-16 16:16 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=1471243&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: ShireII (shireii) Assigned to: Nobody/Anonymous (nobody) Summary: Visual Studio 2005 CRT error handler Initial Comment: Visual Studio 2005 CRT has new default behavior for invalid parameters. When invalid parameter is passed, function calls CrtDbgReport, and after - handler for invalid parameter. Default handler crushes application. Solution - set handler on initialization and restore on uninitization. Sample source code - on attachment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471243&group_id=5470 From noreply at sourceforge.net Sun Apr 16 16:18:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 07:18:29 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 17:40 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-04-16 15:18 Message: Logged In: YES user_id=113328 Thomas, As I've just got my own build environment set up with the free MS compiler, I thought I'd show off and build my own copy :-) I can confirm that with the patch, the pywin32 installer also works (the one real-life case of a preinstall script that I know). Also, this patch fixes another funny issue I'd not quite managed to isolate - installers were failing to compile .py files (and conversely, the uninstaller was leaving .pyc files behind). Paul. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-12 21:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-11 18:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-06 21:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 19:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Sun Apr 16 21:20:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 12:20:00 -0700 Subject: [ python-Bugs-1470502 ] Mention coercion removal in Misc/NEWS Message-ID: Bugs item #1470502, was opened at 2006-04-14 12:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470502&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Mention coercion removal in Misc/NEWS Initial Comment: Neal has been ripping out __coerce__ but Misc/NEWS doesn't mention that. Should be mentioned (along with test_coercion being removed). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-16 12:20 Message: Logged In: YES user_id=33168 This was done AFAIK. There will be more coercion removals coming as soon as I have time. I'll update NEWS when I do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470502&group_id=5470 From noreply at sourceforge.net Sun Apr 16 21:23:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 12:23:54 -0700 Subject: [ python-Bugs-1471407 ] setup.py --help-commands exception Message-ID: Bugs item #1471407, was opened at 2006-04-16 12:23 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=1471407&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: James William Pye (jwpye) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py --help-commands exception Initial Comment: >From a recent trunk build(2.5a1) on FreeBSD 6.1: jwp at lit:/src/org/pgfoundry/python/fe/local % /usr/dev/bin/python ./setup.py --help-commands Standard commands: build build everything needed to install build_py "build" pure Python modules (copy to build directory) build_ext build C/C++ extensions (compile/link to build directory) build_clib build C/C++ libraries used by Python extensions build_scripts "build" scripts (copy and fixup #! line) clean clean up temporary files from 'build' command install install everything from build directory install_lib install all Python modules (extensions and pure Python) install_headers install C/C++ header files install_scripts install scripts (Python or otherwise) install_data install data files sdist create a source distribution (tarball, zip file, etc.) Traceback (most recent call last): File "./setup.py", line 52, in setup(defaults) File "./setup.py", line 46, in setup d = distutils.core.setup(**kw) File "/usr/dev/lib/python2.5/distutils/core.py", line 137, in setup ok = dist.parse_command_line() File "/usr/dev/lib/python2.5/distutils/dist.py", line 455, in parse_command_line if self.handle_display_options(option_order): File "/usr/dev/lib/python2.5/distutils/dist.py", line 680, in handle_display_options self.print_commands() File "/usr/dev/lib/python2.5/distutils/dist.py", line 758, in print_commands max_length) File "/usr/dev/lib/python2.5/distutils/dist.py", line 720, in print_command_list klass = self.get_command_class(cmd) File "/usr/dev/lib/python2.5/distutils/dist.py", line 851, in get_command_class raise DistutilsModuleError("invalid command '%s'" % command) distutils.errors.DistutilsModuleError: invalid command 'register' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&group_id=5470 From noreply at sourceforge.net Sun Apr 16 22:19:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 13:19:38 -0700 Subject: [ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x Message-ID: Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-16 22:19 Message: Logged In: YES user_id=11105 I can confirm that both current Python SVN as well as ctypes CVS pass the testsuite under FreeBSD 6.0. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-16 05:03 Message: Logged In: YES user_id=250749 In that case, it would be worth confirming whether later versions of FreeBSD (at least 5.4, better 6.0) are also affected. I don't know whether there's anyone from DragonflyBSD active - its a FreeBSD 4.x offshoot. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-15 22:26 Message: Logged In: YES user_id=11105 Committed as 45440. For NetBSD, this change seems not to be required - ctypes works fine as it is (I'm testing this on the SF compilefarm host, which has NetBSD 2.0.2). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-15 13:18 Message: Logged In: YES user_id=250749 Your suggested change does indeed get the test to pass on this system. Given the history and relationship of [Free/Net/Open]BSD, I would suggest that for x86 it is very likely that you will need to add defined(__NetBSD__) clauses as well. >From my POV this bug can now be closed. Thanks, Thomas. BTW, the actual patch applied was: --- ffi.c.orig Tue Apr 4 05:26:32 2006 +++ ffi.c Sat Apr 15 21:02:16 2006 @@ -121,7 +121,7 @@ switch (cif->rtype->type) { case FFI_TYPE_VOID: -#if !defined(X86_WIN32) && !defined(__OpenBSD__) +#if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__FreeBSD__) case FFI_TYPE_STRUCT: #endif case FFI_TYPE_SINT64: @@ -135,7 +135,7 @@ cif->flags = FFI_TYPE_SINT64; break; -#if defined(X86_WIN32) || defined(__OpenBSD__) +#if defined(X86_WIN32) || defined(__OpenBSD__) || defined(__FreeBSD__) case FFI_TYPE_STRUCT: if (cif->rtype->size == 1) { ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 From noreply at sourceforge.net Sun Apr 16 22:21:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 13:21:15 -0700 Subject: [ python-Bugs-1471423 ] reload(ctypes) leaks references Message-ID: Bugs item #1471423, was opened at 2006-04-16 22: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=1471423&group_id=5470 Please note that this 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 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: reload(ctypes) leaks references Initial Comment: Found by Neal Norwitz, reload(ctypes) leaks references: >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34251 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34786 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [35321 refs] >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 From noreply at sourceforge.net Sun Apr 16 22:34:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 13:34:03 -0700 Subject: [ python-Bugs-1471427 ] tarfile.py chokes on long names Message-ID: Bugs item #1471427, was opened at 2006-04-16 22:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470 Please note that this 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 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py chokes on long names Initial Comment: The following bug is reproducible on Py 2.4.3 and 2.5. It was tested on Windows. You need a tarfile with a long file name that triggers the GNU LONGNAME extension. Extracting such a file gives me an IO error because it tries to create a file with a slash at the end. This is because # Some old tar programs represent a directory as a regular # file with a trailing slash. if tarinfo.isreg() and tarinfo.name.endswith("/ "): tarinfo.type = DIRTYPE sets the type incorrectly after it was called from the callback proc which has no possiblity to set the name of the intermediary tarinfo class because it is instantiated in the next-method. So this yields a directory which should be a file which is obviously wrong. Might be related to commit 41340 "Patch #1338314, Bug #1336623". (At least the code changed there is causing this bug). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470 From noreply at sourceforge.net Sun Apr 16 22:34:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Apr 2006 13:34:59 -0700 Subject: [ python-Bugs-1471427 ] tarfile.py chokes on long names Message-ID: Bugs item #1471427, was opened at 2006-04-16 22:34 Message generated for change (Comment added) made by alexanderweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470 Please note that this 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 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py chokes on long names Initial Comment: The following bug is reproducible on Py 2.4.3 and 2.5. It was tested on Windows. You need a tarfile with a long file name that triggers the GNU LONGNAME extension. Extracting such a file gives me an IO error because it tries to create a file with a slash at the end. This is because # Some old tar programs represent a directory as a regular # file with a trailing slash. if tarinfo.isreg() and tarinfo.name.endswith("/ "): tarinfo.type = DIRTYPE sets the type incorrectly after it was called from the callback proc which has no possiblity to set the name of the intermediary tarinfo class because it is instantiated in the next-method. So this yields a directory which should be a file which is obviously wrong. Might be related to commit 41340 "Patch #1338314, Bug #1336623". (At least the code changed there is causing this bug). ---------------------------------------------------------------------- >Comment By: Alexander Schremmer (alexanderweb) Date: 2006-04-16 22:34 Message: Logged In: YES user_id=254738 Hmm, I just want to clarify that tarfile doesn't give the IO error (it passes silently) but my code that expects a file instead of a directory ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470 From noreply at sourceforge.net Mon Apr 17 16:07:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 07:07:48 -0700 Subject: [ python-Bugs-1451717 ] OS/X on i386 framework build Message-ID: Bugs item #1451717, was opened at 2006-03-16 23:22 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: OS/X on i386 framework build Initial Comment: in Makefile.pre (374) it hard codes the architecture to 'ppc' which isn't correct for the new x86 boxes. this needs to be i386 for the framework install to actually build on the new macs. regards Ian ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-17 16:07 Message: Logged In: YES user_id=580910 BTW. The 'also' bit has been fixed in the trunk. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:21 Message: Logged In: YES user_id=580910 This is a duplicate of bug 1447587 ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2006-03-16 23:34 Message: Logged In: YES user_id=5209 also.. in plat-mac/applesingle.py the fields AS_HEADER_FORMAT and AS_ENTRY_FORMAT need a '>' infront of the definitions AS_HEADER_FORMAT=">LL16sh" AS_ENTRY_FORMAT=">lll" (this is what the system-packaged python has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470 From noreply at sourceforge.net Mon Apr 17 16:19:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 07:19:10 -0700 Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2 Message-ID: Bugs item #944394, was opened at 2004-04-29 11:02 Message generated for change (Comment added) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this 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 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris ---------------------------------------------------------------------- >Comment By: Chris Withers (fresh) Date: 2006-04-17 14:19 Message: Logged In: YES user_id=24723 I still feel there could be more. I guess the best course, for me, would be to leave this open but at a really low priority. However, I probably wouldn't scream too much if the issue was closed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:49 Message: Logged In: YES user_id=261020 They are here: http://docs.python.org/lib/urllib2-examples.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-04-15 18:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 17:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-06-01 08:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-05-31 21:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 From noreply at sourceforge.net Mon Apr 17 16:26:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 07:26:42 -0700 Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2 Message-ID: Bugs item #944394, was opened at 2004-04-29 12:02 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this 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 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-17 15:26 Message: Logged In: YES user_id=261020 Do you have any specific suggestions for what is unhelpful and/or missing? Otherwise, nothing is likely to change. Note that a little was added at the bottom of this page in 2.4, explaining how OpenerDirector uses the handlers to open URLs: http://docs.python.org/lib/opener-director-objects.html Looking at the top-level page, I guess an introduction / overview would help? Did you have other stuff in mind too? ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-04-17 15:19 Message: Logged In: YES user_id=24723 I still feel there could be more. I guess the best course, for me, would be to leave this open but at a really low priority. However, I probably wouldn't scream too much if the issue was closed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 19:49 Message: Logged In: YES user_id=261020 They are here: http://docs.python.org/lib/urllib2-examples.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-04-15 19:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-06-01 09:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-05-31 22:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 From noreply at sourceforge.net Mon Apr 17 16:44:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 07:44:10 -0700 Subject: [ python-Bugs-1193190 ] MACOSX_DEPLOYMENT_TARGET checked incorrectly Message-ID: Bugs item #1193190, was opened at 2005-05-01 02:15 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Bob Ippolito (etrepum) Summary: MACOSX_DEPLOYMENT_TARGET checked incorrectly Initial Comment: MACOSX_DEPLOYMENT_TARGET should be checked to be >= the configure time value (or not set). Currently, it checks for equality. For example, this is necessary in order to use a Python built for Mac OS X 10.3 but build an extension with features specific to Mac OS X 10.4. Backport candidate to 2.4, patches attached. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-17 16:44 Message: Logged In: YES user_id=580910 Applied as revision 45490 on the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 From noreply at sourceforge.net Mon Apr 17 17:58:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 08:58:01 -0700 Subject: [ python-Bugs-1471806 ] IDLE does not start 2.4.3 Message-ID: Bugs item #1471806, was opened at 2006-04-17 11: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=1471806&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 From noreply at sourceforge.net Mon Apr 17 20:50:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 11:50:12 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by atler_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-17 20:50 Message: Logged In: YES user_id=1497957 /me confirms ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 17:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 16:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-15 09:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 13:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 07:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 00:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 23:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 22:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 15:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 14:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 12:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 12:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 12:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 07:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Mon Apr 17 22:02:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 13:02:09 -0700 Subject: [ python-Bugs-1471934 ] Python libcrypt build problem on Solaris 8 Message-ID: Bugs item #1471934, was opened at 2006-04-17 20: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=1471934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: Python libcrypt build problem on Solaris 8 Initial Comment: Python 2.5a1 and Python 2.4.3 both build incorrectly on Solaris 8 when compiled in 64-bit mode, using Sun Studio 11 cc. Here is the diagnostic: cc -O -xarch=v9 -G build/temp.solaris-2.8-sun4u-2.5/cryptmodule.o -L/u/cs/fac/eggert/seasnet/prefix/lib -lcrypt -o build/lib.solaris-2.8-sun4u-2.5/crypt.so ld: fatal: library -lcrypt: not found ld: fatal: File processing errors. No output written to build/lib.solaris-2.8-sun4u-2.5/crypt.so The problem is that setup.py looks at 32-bit libraries when trying to decide whether a 64-bit build will work. Using LIBS=' -lcrypt_i' does not work around the problem, since the LIBS setting is not exported to the module build. I'll attach a proposed patch to the README file to warn about the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471934&group_id=5470 From noreply at sourceforge.net Mon Apr 17 22:07:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 13:07:39 -0700 Subject: [ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8 Message-ID: Bugs item #1471938, was opened at 2006-04-17 20:07 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=1471938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: curses mvwgetnstr build problem on Solaris 8 Initial Comment: The _curses extension doesn't build on Solaris 8 (64-bit) due to the following problem: building '_curses' extension cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include -I/u/cs/fac/eggert/seasnet/prefix/include -I./Include -I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c /w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c -o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o "/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c", line 822: warning: implicit function declaration: mvwgetnstr cc -O -xarch=v9 -G build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o -L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses -ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension This problem occurs with both 2.4.3 and 2.5a1. I'll attach the obvious patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470 From noreply at sourceforge.net Mon Apr 17 22:26:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 13:26:24 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-08 18:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 13:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 22:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-10 17:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 14:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Mon Apr 17 23:22:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 14:22:03 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 23:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the stack (which certainly wouldn't be the case here). Allocation on the stack is cheap, and over-allocation doesn't hurt. Please change the patch to use automatic variables. It will become simpler and more maintainable that way (in addition, it should also become minimally faster). ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 22:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 02:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 23:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 18 00:10:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 15:10:42 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-08 18:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 15:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 14:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the stack (which certainly wouldn't be the case here). Allocation on the stack is cheap, and over-allocation doesn't hurt. Please change the patch to use automatic variables. It will become simpler and more maintainable that way (in addition, it should also become minimally faster). ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 13:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 22:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-10 17:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 14:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 18 00:20:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 15:20:25 -0700 Subject: [ python-Bugs-1471985 ] mimetools module getencoding error Message-ID: Bugs item #1471985, was opened at 2006-04-17 22: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=1471985&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: James G. sack (jim) (jgsack) Assigned to: Nobody/Anonymous (nobody) Summary: mimetools module getencoding error Initial Comment: in Python 2.4.1 --------------- (accessing mimetools via utllib..) getencoding() returns '7bit' when header contains Content-Type: text/html; charset=UTF-8 shouldn't that substitute for a absent transfer-encoding field? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471985&group_id=5470 From noreply at sourceforge.net Tue Apr 18 00:51:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 15:51:25 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-18 00:51 Message: Logged In: YES user_id=21627 The big win is in simplification of the code. Also, we are not talking about 10k here. On Linux, sock_addr_t is 128 bytes. Take a look at set_error: it allocates 100 bytes for an error buffer. Or sock_repr: 512 bytes for a buffer. Or socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex: 16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes Or, looking at other modules: symtable.c:check_unoptimized: 300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv: 2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on. Don't worry about stack consumption. Or, if you do, analyse the Python source code, and fix the big offenders first. Premature optimization is the root of all evil. ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-18 00:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 23:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the stack (which certainly wouldn't be the case here). Allocation on the stack is cheap, and over-allocation doesn't hurt. Please change the patch to use automatic variables. It will become simpler and more maintainable that way (in addition, it should also become minimally faster). ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 22:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 07:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 02:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 23:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 18 00:53:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 15:53:19 -0700 Subject: [ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8 Message-ID: Bugs item #1471938, was opened at 2006-04-17 22:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: curses mvwgetnstr build problem on Solaris 8 Initial Comment: The _curses extension doesn't build on Solaris 8 (64-bit) due to the following problem: building '_curses' extension cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include -I/u/cs/fac/eggert/seasnet/prefix/include -I./Include -I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c /w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c -o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o "/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c", line 822: warning: implicit function declaration: mvwgetnstr cc -O -xarch=v9 -G build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o -L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses -ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension This problem occurs with both 2.4.3 and 2.5a1. I'll attach the obvious patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-18 00:53 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470 From noreply at sourceforge.net Tue Apr 18 01:05:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 16:05:54 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-08 18:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 16:05 Message: Logged In: YES user_id=24670 > The big win is in simplification of the code. What do you call "big simplification"? Several malloc/free calls and appropriate NULL checks? Aside from stack usage issues the big loss here is portability - we either need to use some fixed length buffer with the size sufficient to hold any type of address (ugly!) or use sockaddr_storage, which may not exist on all platforms supported by the python. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 15:51 Message: Logged In: YES user_id=21627 The big win is in simplification of the code. Also, we are not talking about 10k here. On Linux, sock_addr_t is 128 bytes. Take a look at set_error: it allocates 100 bytes for an error buffer. Or sock_repr: 512 bytes for a buffer. Or socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex: 16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes Or, looking at other modules: symtable.c:check_unoptimized: 300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv: 2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on. Don't worry about stack consumption. Or, if you do, analyse the Python source code, and fix the big offenders first. Premature optimization is the root of all evil. ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 15:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 14:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the stack (which certainly wouldn't be the case here). Allocation on the stack is cheap, and over-allocation doesn't hurt. Please change the patch to use automatic variables. It will become simpler and more maintainable that way (in addition, it should also become minimally faster). ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 13:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 22:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-10 17:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 14:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 18 02:00:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 17:00:44 -0700 Subject: [ python-Bugs-532646 ] Recursive class instance "error" Message-ID: Bugs item #532646, was opened at 2002-03-20 10:56 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 Please note that this 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.3 >Status: Open >Resolution: None Priority: 5 Submitted By: Gregor Mirai (gregmi) Assigned to: Guido van Rossum (gvanrossum) Summary: Recursive class instance "error" Initial Comment: If one writes the following code (tested on Python 2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 98, NT, 2000) one can easily produce several "errors". MacOS X, MacOS X Server (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name, return A() ------------------------------------------ >>> a=A() >>> a.foo Segmentation fault Win98, NT, 2000 (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name return A() ------------------------------------------ >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-04-17 17:00 Message: Logged In: YES user_id=357491 This was not fixed for new-style classes and still segfaults the interpreter at least back to 2.4. Reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 14:50 Message: Logged In: YES user_id=6380 It was very specific to __call__ after all, and I found an example that didn't involve __getattr__. See the comments I checked in as part of the fix in classobject.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 13:41 Message: Logged In: YES user_id=6380 Hm. I'm tracing this in the debugger now, and it appears that the problem is when trying to *print* an A instance. The statement a.foo causes the problem simply because it returns an A instance. (Proof: "a=A().foo; print a" fails in the print.) I think that instance_call may not be the real cause of the problem... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-12 15:38 Message: Logged In: YES user_id=33168 The problem is that there is mutual recursion between instance_call() and PyObject_Call(). The recursion apparently goes through the eval_frame() loop. This patch increases the recursion depth so the mutual recursion will eventually end (otherwise, the stack grows without bounds). ISTM the first check SHOULD be reached, but it is not. I don't understand why. The recursion error must be set in eval_frame(). The first block in the patch could be just this line: ++tstate->recursion_depth; I didn't do it that way, since I didn't expect returning to eval_frame(). I'm not sure if it's guaranteed to return to eval_frame() which is why I left the first condition in with the comment. I suppose the comment should say something like: /* this condition doesn't seem to be triggered, the recursion depth limit is exceeded in eval_frame */ The test for recursion_depth is necessary to ensure that the recursion error isn't overwritten. If this check is removed, the follow exception is raised: AttributeError: A instance has no __call__ method Hopefully this makes sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 09:08 Message: Logged In: YES user_id=6380 Can you explain how the fix works? Why does the first comment say /* this shouldn't be reached, but just in case */ and why is this test necesary if (tstate->recursion_depth < Py_GetRecursionLimit()) { ??? And who *does* report the recursion error? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 15:52 Message: Logged In: YES user_id=33168 The recursion fields are shared in the new patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:35 Message: Logged In: YES user_id=33168 That sounds more reasonable. I'll take a look and see if they can be integrated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:27 Message: Logged In: YES user_id=6380 Fair enough. Ideally this should share the recursion_limit variable from ceval.c and the recursion_depth field of the stack frame. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:23 Message: Logged In: YES user_id=33168 I don't know. I tried to come up with other test cases and failed. Tried __str__ and __getitem__. Also tried new-style classes. The problem was that the code bounced back and forth between PyObject_Call() & instance_call() (mutual recursion). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:08 Message: Logged In: YES user_id=6380 Is this fix enough? Aren't there lots of other ways to generate the same error? E.g. new-style classes (where this particular example doesn't apply, but others might). Or is this specific to instance_call? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 12:21 Message: Logged In: YES user_id=33168 The attached patch stops the segfault and raises an exception: TypeError: 'A' max recursion limit (100000) exceeded I'm not sure if this is genarally applicable, or what a reasonable # is. 100,000 was a guess and should probably be made a #def w/comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-21 01:47 Message: Logged In: NO >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf This is normal behavior. The code at the top is buggy. The correct one is: class A: def __getattr__(self, name): if name == '__repr__': return self.__repr__() print name return A() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-20 14:10 Message: Logged In: YES user_id=6380 This is buggy user code. But the segfault should be fixed if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 From noreply at sourceforge.net Tue Apr 18 05:52:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 20:52:57 -0700 Subject: [ python-Bugs-1472084 ] sgmllib do_tag description error Message-ID: Bugs item #1472084, was opened at 2006-04-18 03: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=1472084&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: James G. sack (jim) (jgsack) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib do_tag description error Initial Comment: section 13.2 sgmllib -- Simple SGML parser do_tag(attributes) This method is called to process an opening tag that does not come with a matching closing tag... (that's incorrect) It should say something like This method is called to process an opening tag (only) if there is no corresponding start_tag function defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472084&group_id=5470 From noreply at sourceforge.net Tue Apr 18 06:37:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 21:37:06 -0700 Subject: [ python-Bugs-532646 ] Recursive class instance "error" Message-ID: Bugs item #532646, was opened at 2002-03-20 10:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Mirai (gregmi) Assigned to: Guido van Rossum (gvanrossum) Summary: Recursive class instance "error" Initial Comment: If one writes the following code (tested on Python 2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 98, NT, 2000) one can easily produce several "errors". MacOS X, MacOS X Server (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name, return A() ------------------------------------------ >>> a=A() >>> a.foo Segmentation fault Win98, NT, 2000 (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name return A() ------------------------------------------ >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-17 21:37 Message: Logged In: YES user_id=33168 Please add a test case to Lib/test/crashers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-04-17 17:00 Message: Logged In: YES user_id=357491 This was not fixed for new-style classes and still segfaults the interpreter at least back to 2.4. Reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 14:50 Message: Logged In: YES user_id=6380 It was very specific to __call__ after all, and I found an example that didn't involve __getattr__. See the comments I checked in as part of the fix in classobject.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 13:41 Message: Logged In: YES user_id=6380 Hm. I'm tracing this in the debugger now, and it appears that the problem is when trying to *print* an A instance. The statement a.foo causes the problem simply because it returns an A instance. (Proof: "a=A().foo; print a" fails in the print.) I think that instance_call may not be the real cause of the problem... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-12 15:38 Message: Logged In: YES user_id=33168 The problem is that there is mutual recursion between instance_call() and PyObject_Call(). The recursion apparently goes through the eval_frame() loop. This patch increases the recursion depth so the mutual recursion will eventually end (otherwise, the stack grows without bounds). ISTM the first check SHOULD be reached, but it is not. I don't understand why. The recursion error must be set in eval_frame(). The first block in the patch could be just this line: ++tstate->recursion_depth; I didn't do it that way, since I didn't expect returning to eval_frame(). I'm not sure if it's guaranteed to return to eval_frame() which is why I left the first condition in with the comment. I suppose the comment should say something like: /* this condition doesn't seem to be triggered, the recursion depth limit is exceeded in eval_frame */ The test for recursion_depth is necessary to ensure that the recursion error isn't overwritten. If this check is removed, the follow exception is raised: AttributeError: A instance has no __call__ method Hopefully this makes sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 09:08 Message: Logged In: YES user_id=6380 Can you explain how the fix works? Why does the first comment say /* this shouldn't be reached, but just in case */ and why is this test necesary if (tstate->recursion_depth < Py_GetRecursionLimit()) { ??? And who *does* report the recursion error? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 15:52 Message: Logged In: YES user_id=33168 The recursion fields are shared in the new patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:35 Message: Logged In: YES user_id=33168 That sounds more reasonable. I'll take a look and see if they can be integrated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:27 Message: Logged In: YES user_id=6380 Fair enough. Ideally this should share the recursion_limit variable from ceval.c and the recursion_depth field of the stack frame. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:23 Message: Logged In: YES user_id=33168 I don't know. I tried to come up with other test cases and failed. Tried __str__ and __getitem__. Also tried new-style classes. The problem was that the code bounced back and forth between PyObject_Call() & instance_call() (mutual recursion). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:08 Message: Logged In: YES user_id=6380 Is this fix enough? Aren't there lots of other ways to generate the same error? E.g. new-style classes (where this particular example doesn't apply, but others might). Or is this specific to instance_call? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 12:21 Message: Logged In: YES user_id=33168 The attached patch stops the segfault and raises an exception: TypeError: 'A' max recursion limit (100000) exceeded I'm not sure if this is genarally applicable, or what a reasonable # is. 100,000 was a guess and should probably be made a #def w/comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-21 01:47 Message: Logged In: NO >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf This is normal behavior. The code at the top is buggy. The correct one is: class A: def __getattr__(self, name): if name == '__repr__': return self.__repr__() print name return A() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-20 14:10 Message: Logged In: YES user_id=6380 This is buggy user code. But the segfault should be fixed if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 From noreply at sourceforge.net Tue Apr 18 08:04:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Apr 2006 23:04:18 -0700 Subject: [ python-Bugs-1471806 ] IDLE does not start 2.4.3 Message-ID: Bugs item #1471806, was opened at 2006-04-17 08:58 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Erin (egrimes) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 From noreply at sourceforge.net Tue Apr 18 10:09:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 01:09:10 -0700 Subject: [ python-Bugs-532646 ] Recursive class instance "error" Message-ID: Bugs item #532646, was opened at 2002-03-20 13:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Mirai (gregmi) >Assigned to: Brett Cannon (bcannon) Summary: Recursive class instance "error" Initial Comment: If one writes the following code (tested on Python 2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 98, NT, 2000) one can easily produce several "errors". MacOS X, MacOS X Server (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name, return A() ------------------------------------------ >>> a=A() >>> a.foo Segmentation fault Win98, NT, 2000 (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name return A() ------------------------------------------ >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-18 04:09 Message: Logged In: YES user_id=6380 Ironically, I just found the same (?) crash in the p3yk branch, in test_class.py (which is now testing new-style classes for compatibility with the behavior of classic classes). I can't fix this myself, so assigning to Brett. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-18 00:37 Message: Logged In: YES user_id=33168 Please add a test case to Lib/test/crashers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-04-17 20:00 Message: Logged In: YES user_id=357491 This was not fixed for new-style classes and still segfaults the interpreter at least back to 2.4. Reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 17:50 Message: Logged In: YES user_id=6380 It was very specific to __call__ after all, and I found an example that didn't involve __getattr__. See the comments I checked in as part of the fix in classobject.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 16:41 Message: Logged In: YES user_id=6380 Hm. I'm tracing this in the debugger now, and it appears that the problem is when trying to *print* an A instance. The statement a.foo causes the problem simply because it returns an A instance. (Proof: "a=A().foo; print a" fails in the print.) I think that instance_call may not be the real cause of the problem... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-12 18:38 Message: Logged In: YES user_id=33168 The problem is that there is mutual recursion between instance_call() and PyObject_Call(). The recursion apparently goes through the eval_frame() loop. This patch increases the recursion depth so the mutual recursion will eventually end (otherwise, the stack grows without bounds). ISTM the first check SHOULD be reached, but it is not. I don't understand why. The recursion error must be set in eval_frame(). The first block in the patch could be just this line: ++tstate->recursion_depth; I didn't do it that way, since I didn't expect returning to eval_frame(). I'm not sure if it's guaranteed to return to eval_frame() which is why I left the first condition in with the comment. I suppose the comment should say something like: /* this condition doesn't seem to be triggered, the recursion depth limit is exceeded in eval_frame */ The test for recursion_depth is necessary to ensure that the recursion error isn't overwritten. If this check is removed, the follow exception is raised: AttributeError: A instance has no __call__ method Hopefully this makes sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 12:08 Message: Logged In: YES user_id=6380 Can you explain how the fix works? Why does the first comment say /* this shouldn't be reached, but just in case */ and why is this test necesary if (tstate->recursion_depth < Py_GetRecursionLimit()) { ??? And who *does* report the recursion error? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 18:52 Message: Logged In: YES user_id=33168 The recursion fields are shared in the new patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 16:35 Message: Logged In: YES user_id=33168 That sounds more reasonable. I'll take a look and see if they can be integrated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 16:27 Message: Logged In: YES user_id=6380 Fair enough. Ideally this should share the recursion_limit variable from ceval.c and the recursion_depth field of the stack frame. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 16:23 Message: Logged In: YES user_id=33168 I don't know. I tried to come up with other test cases and failed. Tried __str__ and __getitem__. Also tried new-style classes. The problem was that the code bounced back and forth between PyObject_Call() & instance_call() (mutual recursion). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 16:08 Message: Logged In: YES user_id=6380 Is this fix enough? Aren't there lots of other ways to generate the same error? E.g. new-style classes (where this particular example doesn't apply, but others might). Or is this specific to instance_call? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 15:21 Message: Logged In: YES user_id=33168 The attached patch stops the segfault and raises an exception: TypeError: 'A' max recursion limit (100000) exceeded I'm not sure if this is genarally applicable, or what a reasonable # is. 100,000 was a guess and should probably be made a #def w/comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-21 04:47 Message: Logged In: NO >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf This is normal behavior. The code at the top is buggy. The correct one is: class A: def __getattr__(self, name): if name == '__repr__': return self.__repr__() print name return A() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-20 17:10 Message: Logged In: YES user_id=6380 This is buggy user code. But the segfault should be fixed if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 From noreply at sourceforge.net Tue Apr 18 11:20:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 02:20:00 -0700 Subject: [ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Message-ID: Bugs item #1472173, was opened at 2006-04-18 11: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=1472173&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 From noreply at sourceforge.net Tue Apr 18 11:28:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 02:28:35 -0700 Subject: [ python-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib? Message-ID: Feature Requests item #1472176, was opened at 2006-04-18 11:28 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=1472176&group_id=5470 Please note that this 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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: "idna" encoding (drawing unicodedata) necessary in httplib? Initial Comment: httplib employs the "idna" encoding. that leads to errors in py2exe/cxfreeze. And if forced into the installer, it draws the 400kB+ unicodedata.pyd (on Win) in innocent small apps. Otherwise no normal technical modules draw the unicodedata. Is that really necessary? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470 From noreply at sourceforge.net Tue Apr 18 11:32:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 02:32:59 -0700 Subject: [ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Message-ID: Bugs item #1472173, was opened at 2006-04-18 10:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-04-18 10:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 From noreply at sourceforge.net Tue Apr 18 11:49:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 02:49:09 -0700 Subject: [ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected bp's Message-ID: Bugs item #1472191, was opened at 2006-04-18 09: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=1472191&group_id=5470 Please note that this 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 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'clear' command doesn't clear selected bp's Initial Comment: Pdb 'clear x' command doesn't clear selected breakpoints that are already set: $ ./python -m pdb ../test.py > /home/xyz/python/test.py(3)() -> def t(x): (Pdb) break 5 Breakpoint 1 at /home/xyz/python/test.py:5 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /home/xyz/python/test.py:5 (Pdb) clear 1 No breakpoint numbered 1 (Pdb) ... for i in numberlist: * if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): print 'No breakpoint numbered', i ... Each i is a string and it's compared to 0 and len(...), so condition * is always True. The fix is trivial: * if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)): Fix is in #1472184 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470 From noreply at sourceforge.net Tue Apr 18 11:49:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 02:49:45 -0700 Subject: [ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected bp's Message-ID: Bugs item #1472191, was opened at 2006-04-18 09:49 Message generated for change (Settings changed) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470 Please note that this 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: 6 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'clear' command doesn't clear selected bp's Initial Comment: Pdb 'clear x' command doesn't clear selected breakpoints that are already set: $ ./python -m pdb ../test.py > /home/xyz/python/test.py(3)() -> def t(x): (Pdb) break 5 Breakpoint 1 at /home/xyz/python/test.py:5 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /home/xyz/python/test.py:5 (Pdb) clear 1 No breakpoint numbered 1 (Pdb) ... for i in numberlist: * if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): print 'No breakpoint numbered', i ... Each i is a string and it's compared to 0 and len(...), so condition * is always True. The fix is trivial: * if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)): Fix is in #1472184 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&group_id=5470 From noreply at sourceforge.net Tue Apr 18 11:59:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 02:59:22 -0700 Subject: [ python-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib? Message-ID: Feature Requests item #1472176, was opened at 2006-04-18 11:28 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470 Please note that this 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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: "idna" encoding (drawing unicodedata) necessary in httplib? Initial Comment: httplib employs the "idna" encoding. that leads to errors in py2exe/cxfreeze. And if forced into the installer, it draws the 400kB+ unicodedata.pyd (on Win) in innocent small apps. Otherwise no normal technical modules draw the unicodedata. Is that really necessary? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-04-18 11:59 Message: Logged In: YES user_id=38388 I agree - in most cases, ASCII will be used for hostnames (where the idna encoding is being used in httplib). A little helper function to first try .encode('ascii') and then revert to .encode('idna') would do wonders. Patches are welcome ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470 From noreply at sourceforge.net Tue Apr 18 14:16:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 05:16:14 -0700 Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string Message-ID: Bugs item #1472251, was opened at 2006-04-18 12:16 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=1472251&group_id=5470 Please note that this 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 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'run' crashes when the it's first argument is non-string Initial Comment: Pdb 'run/runeval' commands fails to check the type of given argument.When argument to 'run/runeval' is non-string the functions crashes with further impilications on (correctly)invoking this functions: Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31) >>> def x(): pass >>> import pdb >>> pdb.run(x()) Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 363, in run cmd = cmd+'\n' TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run('x()') > /home/jkk/python/python-svn/Lib/pdb.py(1113)run() -> Pdb().run(statement, globals, locals) (Pdb) # CTRL-D pressed Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/home/jkk/python/python-svn/Lib/bdb.py", line 67, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit The solution is to simply ensure that the first argument passed to the 'run/runeval' functions is string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 From noreply at sourceforge.net Tue Apr 18 14:16:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 05:16:58 -0700 Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string Message-ID: Bugs item #1472251, was opened at 2006-04-18 12:16 Message generated for change (Settings changed) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 Please note that this 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: 6 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'run' crashes when the it's first argument is non-string Initial Comment: Pdb 'run/runeval' commands fails to check the type of given argument.When argument to 'run/runeval' is non-string the functions crashes with further impilications on (correctly)invoking this functions: Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31) >>> def x(): pass >>> import pdb >>> pdb.run(x()) Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 363, in run cmd = cmd+'\n' TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run('x()') > /home/jkk/python/python-svn/Lib/pdb.py(1113)run() -> Pdb().run(statement, globals, locals) (Pdb) # CTRL-D pressed Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/home/jkk/python/python-svn/Lib/bdb.py", line 67, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit The solution is to simply ensure that the first argument passed to the 'run/runeval' functions is string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 From noreply at sourceforge.net Tue Apr 18 14:36:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 05:36:42 -0700 Subject: [ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string Message-ID: Bugs item #1472251, was opened at 2006-04-18 12:16 Message generated for change (Comment added) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 Please note that this 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: 6 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'run' crashes when the it's first argument is non-string Initial Comment: Pdb 'run/runeval' commands fails to check the type of given argument.When argument to 'run/runeval' is non-string the functions crashes with further impilications on (correctly)invoking this functions: Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31) >>> def x(): pass >>> import pdb >>> pdb.run(x()) Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 363, in run cmd = cmd+'\n' TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' >>> pdb.run('x()') > /home/jkk/python/python-svn/Lib/pdb.py(1113)run() -> Pdb().run(statement, globals, locals) (Pdb) # CTRL-D pressed Traceback (most recent call last): File "", line 1, in File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/pdb.py", line 1113, in run Pdb().run(statement, globals, locals) File "/home/jkk/python/python-svn/Lib/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/home/jkk/python/python-svn/Lib/bdb.py", line 67, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit The solution is to simply ensure that the first argument passed to the 'run/runeval' functions is string. ---------------------------------------------------------------------- >Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-04-18 12:36 Message: Logged In: YES user_id=1491175 Patch is in #1472257 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&group_id=5470 From noreply at sourceforge.net Tue Apr 18 17:02:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 08:02:58 -0700 Subject: [ python-Bugs-1471423 ] reload(ctypes) leaks references Message-ID: Bugs item #1471423, was opened at 2006-04-16 22:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 Please note that this 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 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: reload(ctypes) leaks references Initial Comment: Found by Neal Norwitz, reload(ctypes) leaks references: >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34251 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34786 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [35321 refs] >>> ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-18 17:02 Message: Logged In: YES user_id=11105 Fixed in rev. 45535. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 From noreply at sourceforge.net Tue Apr 18 17:20:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 08:20:21 -0700 Subject: [ python-Bugs-1471423 ] reload(ctypes) leaks references Message-ID: Bugs item #1471423, was opened at 2006-04-16 22:21 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: reload(ctypes) leaks references Initial Comment: Found by Neal Norwitz, reload(ctypes) leaks references: >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34251 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [34786 refs] >>> reload(ctypes); gc.collect(); gc.collect(); gc.collect() 128 13 0 [35321 refs] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-18 17:02 Message: Logged In: YES user_id=11105 Fixed in rev. 45535. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471423&group_id=5470 From noreply at sourceforge.net Tue Apr 18 20:51:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 11:51:18 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-16 16:18 Message: Logged In: YES user_id=113328 Thomas, As I've just got my own build environment set up with the free MS compiler, I thought I'd show off and build my own copy :-) I can confirm that with the patch, the pywin32 installer also works (the one real-life case of a preinstall script that I know). Also, this patch fixes another funny issue I'd not quite managed to isolate - installers were failing to compile .py files (and conversely, the uninstaller was leaving .pyc files behind). Paul. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-12 22:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Tue Apr 18 21:08:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 12:08:14 -0700 Subject: [ python-Bugs-532646 ] Recursive class instance "error" Message-ID: Bugs item #532646, was opened at 2002-03-20 10:56 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Mirai (gregmi) Assigned to: Brett Cannon (bcannon) Summary: Recursive class instance "error" Initial Comment: If one writes the following code (tested on Python 2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 98, NT, 2000) one can easily produce several "errors". MacOS X, MacOS X Server (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name, return A() ------------------------------------------ >>> a=A() >>> a.foo Segmentation fault Win98, NT, 2000 (Python 2.1, 2.2) ------------------------------------------ class A: def __getattr__(self, name): print name return A() ------------------------------------------ >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-04-18 12:08 Message: Logged In: YES user_id=357491 The test is already in crashers: infinite_rec_3 . And it is the same crash as in py3k; that's how I found it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-18 01:09 Message: Logged In: YES user_id=6380 Ironically, I just found the same (?) crash in the p3yk branch, in test_class.py (which is now testing new-style classes for compatibility with the behavior of classic classes). I can't fix this myself, so assigning to Brett. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-17 21:37 Message: Logged In: YES user_id=33168 Please add a test case to Lib/test/crashers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-04-17 17:00 Message: Logged In: YES user_id=357491 This was not fixed for new-style classes and still segfaults the interpreter at least back to 2.4. Reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 14:50 Message: Logged In: YES user_id=6380 It was very specific to __call__ after all, and I found an example that didn't involve __getattr__. See the comments I checked in as part of the fix in classobject.c. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 13:41 Message: Logged In: YES user_id=6380 Hm. I'm tracing this in the debugger now, and it appears that the problem is when trying to *print* an A instance. The statement a.foo causes the problem simply because it returns an A instance. (Proof: "a=A().foo; print a" fails in the print.) I think that instance_call may not be the real cause of the problem... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-12 15:38 Message: Logged In: YES user_id=33168 The problem is that there is mutual recursion between instance_call() and PyObject_Call(). The recursion apparently goes through the eval_frame() loop. This patch increases the recursion depth so the mutual recursion will eventually end (otherwise, the stack grows without bounds). ISTM the first check SHOULD be reached, but it is not. I don't understand why. The recursion error must be set in eval_frame(). The first block in the patch could be just this line: ++tstate->recursion_depth; I didn't do it that way, since I didn't expect returning to eval_frame(). I'm not sure if it's guaranteed to return to eval_frame() which is why I left the first condition in with the comment. I suppose the comment should say something like: /* this condition doesn't seem to be triggered, the recursion depth limit is exceeded in eval_frame */ The test for recursion_depth is necessary to ensure that the recursion error isn't overwritten. If this check is removed, the follow exception is raised: AttributeError: A instance has no __call__ method Hopefully this makes sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 09:08 Message: Logged In: YES user_id=6380 Can you explain how the fix works? Why does the first comment say /* this shouldn't be reached, but just in case */ and why is this test necesary if (tstate->recursion_depth < Py_GetRecursionLimit()) { ??? And who *does* report the recursion error? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 15:52 Message: Logged In: YES user_id=33168 The recursion fields are shared in the new patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:35 Message: Logged In: YES user_id=33168 That sounds more reasonable. I'll take a look and see if they can be integrated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:27 Message: Logged In: YES user_id=6380 Fair enough. Ideally this should share the recursion_limit variable from ceval.c and the recursion_depth field of the stack frame. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 13:23 Message: Logged In: YES user_id=33168 I don't know. I tried to come up with other test cases and failed. Tried __str__ and __getitem__. Also tried new-style classes. The problem was that the code bounced back and forth between PyObject_Call() & instance_call() (mutual recursion). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-07 13:08 Message: Logged In: YES user_id=6380 Is this fix enough? Aren't there lots of other ways to generate the same error? E.g. new-style classes (where this particular example doesn't apply, but others might). Or is this specific to instance_call? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-07 12:21 Message: Logged In: YES user_id=33168 The attached patch stops the segfault and raises an exception: TypeError: 'A' max recursion limit (100000) exceeded I'm not sure if this is genarally applicable, or what a reasonable # is. 100,000 was a guess and should probably be made a #def w/comment. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-21 01:47 Message: Logged In: NO >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf This is normal behavior. The code at the top is buggy. The correct one is: class A: def __getattr__(self, name): if name == '__repr__': return self.__repr__() print name return A() ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-20 14:10 Message: Logged In: YES user_id=6380 This is buggy user code. But the segfault should be fixed if possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 From noreply at sourceforge.net Tue Apr 18 21:48:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 12:48:27 -0700 Subject: [ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1 Message-ID: Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this 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: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-18 21:48 Message: Logged In: YES user_id=11105 Compiling .py to .pyc/.pyo works the same way as the preinstall-script: By dynamically loading a pythonXY.dll and calling functions in it. The difference is that there's no error message when loading fails because of missing functions ;-). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-16 16:18 Message: Logged In: YES user_id=113328 Thomas, As I've just got my own build environment set up with the free MS compiler, I thought I'd show off and build my own copy :-) I can confirm that with the patch, the pywin32 installer also works (the one real-life case of a preinstall script that I know). Also, this patch fixes another funny issue I'd not quite managed to isolate - installers were failing to compile .py files (and conversely, the uninstaller was leaving .pyc files behind). Paul. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-12 22:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 From noreply at sourceforge.net Tue Apr 18 22:06:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 13:06:01 -0700 Subject: [ python-Bugs-1472566 ] import module with .dll extension Message-ID: Bugs item #1472566, was opened at 2006-04-18 22:06 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=1472566&group_id=5470 Please note that this 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 Submitted By: svenn (sven_nystrom) Assigned to: Nobody/Anonymous (nobody) Summary: import module with .dll extension Initial Comment: In previous versions, extension modules with the file extension '.dll' could be imported using a single 'import' statement. In 2.5a1 this seems to have changed - here's an example: >>> import minx # Implemented in a .dll - fails Traceback (most recent call last): File "", line 1, in ImportError: No module named minx >>> import imp # Workaround >>> import os >>> minx = imp.load_dynamic('minx', os.getcwd() + '\\minx.dll') I would really like this to remain the same; if that's not possible, it would be helpful if the change itself and a suggested approach were to be included in the documentation. /Sven ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 From noreply at sourceforge.net Wed Apr 19 03:10:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 18:10:57 -0700 Subject: [ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity Message-ID: Bugs item #1472695, was opened at 2006-04-19 01: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=1472695&group_id=5470 Please note that this 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 Submitted By: Peter Maxwell (pm67nz) Assigned to: Nobody/Anonymous (nobody) Summary: 32/64bit pickled Random incompatiblity Initial Comment: The unsigned long integers which make up the state of a Random instance are converted to Python integers via a cast to long in _randommodule.c's random_getstate function, so on a 32bit platform Random.getstate() returns a mix of postitive and negative integers, while on a 64bit platform the negative numbers are replaced by larger positive numbers, their 32bit-2s-complement equivalents. As a result, unpicking a Random instance from a 64bit machine on a 32bit platform produces the error "OverflowError: long int too large to convert to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the resulting object is in a slightly confused state: >>> r32 = cPickle.load(open('r32_3.pickle')) >>> for i in range(3): ... print r64.random(), r32.random() ... 0.237964627092 4292886520.32 0.544229225296 0.544229225296 0.369955166548 4292886520.19 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 From noreply at sourceforge.net Wed Apr 19 04:34:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 19:34:21 -0700 Subject: [ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse Message-ID: Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 From noreply at sourceforge.net Wed Apr 19 06:16:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 21:16:01 -0700 Subject: [ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Message-ID: Bugs item #1472173, was opened at 2006-04-18 02:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-18 21:16 Message: Logged In: YES user_id=33168 Hmmm, it's possible some of the configure magic changed. It might have been inadvertant. Can you attach your config.log? When you did a ./configure it should have printed out some things about readline and searching for it. That might help you diagnose the problem. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-04-18 02:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 From noreply at sourceforge.net Wed Apr 19 06:42:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Apr 2006 21:42:46 -0700 Subject: [ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse Message-ID: Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-19 00:42 Message: Logged In: YES user_id=31435 It doesn't really matter: self->key is either NULL or a Python string object, and neither can be involved in a cycle, so for purposes of cyclic gc it's just a waste of time to pass the key to a visit() callback. The docs could be clearer about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 From noreply at sourceforge.net Wed Apr 19 09:02:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 00:02:52 -0700 Subject: [ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity Message-ID: Bugs item #1472695, was opened at 2006-04-18 18:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 Please note that this 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 Submitted By: Peter Maxwell (pm67nz) Assigned to: Nobody/Anonymous (nobody) Summary: 32/64bit pickled Random incompatiblity Initial Comment: The unsigned long integers which make up the state of a Random instance are converted to Python integers via a cast to long in _randommodule.c's random_getstate function, so on a 32bit platform Random.getstate() returns a mix of postitive and negative integers, while on a 64bit platform the negative numbers are replaced by larger positive numbers, their 32bit-2s-complement equivalents. As a result, unpicking a Random instance from a 64bit machine on a 32bit platform produces the error "OverflowError: long int too large to convert to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the resulting object is in a slightly confused state: >>> r32 = cPickle.load(open('r32_3.pickle')) >>> for i in range(3): ... print r64.random(), r32.random() ... 0.237964627092 4292886520.32 0.544229225296 0.544229225296 0.369955166548 4292886520.19 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 00:02 Message: Logged In: YES user_id=33168 Peter, thanks for the report. Do you think you could work up a patch to correct this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 From noreply at sourceforge.net Wed Apr 19 09:13:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 00:13:14 -0700 Subject: [ python-Bugs-1472566 ] import module with .dll extension Message-ID: Bugs item #1472566, was opened at 2006-04-18 13:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 Please note that this 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 Submitted By: svenn (sven_nystrom) >Assigned to: Martin v. L??wis (loewis) Summary: import module with .dll extension Initial Comment: In previous versions, extension modules with the file extension '.dll' could be imported using a single 'import' statement. In 2.5a1 this seems to have changed - here's an example: >>> import minx # Implemented in a .dll - fails Traceback (most recent call last): File "", line 1, in ImportError: No module named minx >>> import imp # Workaround >>> import os >>> minx = imp.load_dynamic('minx', os.getcwd() + '\\minx.dll') I would really like this to remain the same; if that's not possible, it would be helpful if the change itself and a suggested approach were to be included in the documentation. /Sven ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 00:13 Message: Logged In: YES user_id=33168 I believe this was an intentional change in rev 43622. I don't see any doc associated with the change however. I also thought it was mentioned on python-dev. Martin, shouldn't this be documented at least in Misc/NEWS? I couldn't find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 From noreply at sourceforge.net Wed Apr 19 10:29:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 01:29:37 -0700 Subject: [ python-Bugs-1472827 ] xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes Message-ID: Bugs item #1472827, was opened at 2006-04-19 15: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=1472827&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes Initial Comment: xml.sax.saxutils.XMLGenerator does not escape \r, \n, \t symbols when they are present in the attribute: startElement("name", {"attrib": "value\nvalue"}) will result in which will be normalized by XML parser to According to the XML specs, to preserve this symbols in the attribute values, they should be replaced with \xD; \xA; \x9; Trivial fix is to replace those characters in xml.sax.saxutils.writeattr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&group_id=5470 From noreply at sourceforge.net Wed Apr 19 11:11:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 02:11:17 -0700 Subject: [ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Message-ID: Bugs item #1472173, was opened at 2006-04-18 11:20 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 Please note that this 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: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-04-19 11:11 Message: Logged In: YES user_id=972995 oops, is ok after: apt-get install libreadline5-dev ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 06:16 Message: Logged In: YES user_id=33168 Hmmm, it's possible some of the configure magic changed. It might have been inadvertant. Can you attach your config.log? When you did a ./configure it should have printed out some things about readline and searching for it. That might help you diagnose the problem. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-04-18 11:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 From noreply at sourceforge.net Wed Apr 19 11:41:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 02:41:19 -0700 Subject: [ python-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib? Message-ID: Feature Requests item #1472176, was opened at 2006-04-18 11:28 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470 Please note that this 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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: "idna" encoding (drawing unicodedata) necessary in httplib? Initial Comment: httplib employs the "idna" encoding. that leads to errors in py2exe/cxfreeze. And if forced into the installer, it draws the 400kB+ unicodedata.pyd (on Win) in innocent small apps. Otherwise no normal technical modules draw the unicodedata. Is that really necessary? ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-04-19 11:41 Message: Logged In: YES user_id=972995 a patch attached ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-04-18 11:59 Message: Logged In: YES user_id=38388 I agree - in most cases, ASCII will be used for hostnames (where the idna encoding is being used in httplib). A little helper function to first try .encode('ascii') and then revert to .encode('idna') would do wonders. Patches are welcome ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470 From noreply at sourceforge.net Wed Apr 19 12:26:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 03:26:56 -0700 Subject: [ python-Bugs-1472877 ] Tix: Subwidget names Message-ID: Bugs item #1472877, was opened at 2006-04-19 10: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=1472877&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kievernagel (mkiever) Assigned to: Martin v. L??wis (loewis) Summary: Tix: Subwidget names Initial Comment: My system information: ------------------------------------------ uname -a: Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC 2004 i686 athlon i386 GNU/Linux Python: Python 2.4.1 (#4, Jan 10 2006, 10:53:14) [GCC 3.3.3 (SuSE Linux)] on linux2 and Python 2.3.5 (#1, Sep 12 2005, 14:56:24) [GCC 3.3.3 (SuSE Linux)] on linux2 ------------------------------------------ Using Tix you can produce the following exception: --------------------------------------------------- >>> from Tix import * >>> tk = Tk () >>> b = Balloon () >>> b.subwidget ( 'label' ) Traceback (most recent call last): File "", line 1, in ? File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/Tix. py", line 340, in subwidget return self._nametowidget(n) File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/ Tkinter.py", line 1015, in nametowidget w = w.children[name] KeyError: 'lab' >>> --------------------------------------------------- I found a commentary in Tix.py:TixWidget:__init__ stating that 'subwidget_list' should contain Tix names. But in Tix.py:TixSubWidget:__init__ the python names are used, not the names returned by Tix. I was successful with the following two small additions (+++) near lines 400-450: --------------------------------------------- class TixSubWidget(TixWidget): ... def __init__(self, master, name, destroy_physically=1, check_intermediate=1): ... if (not check_intermediate) or len(plist) < 2: # immediate descendant if check_intermediate: +++ name = plist [0] +++ TixWidget.__init__(self, master, None, None, {'name' : name}) else: ... name = plist [-1] +++ TixWidget.__init__(self, parent, None, None, {'name' : name}) self.destroy_physically = destroy_physically ... --------------------------------------------- This replaces the python name by the name returned from Tix. I have not extensively tested this (sorry). Hope this helps. Matthias Kievernagel (mkiever at web.de) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470 From noreply at sourceforge.net Wed Apr 19 14:42:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 05:42:47 -0700 Subject: [ python-Bugs-1472949 ] shutil.copytree debug message problem Message-ID: Bugs item #1472949, was opened at 2006-04-19 14: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=1472949&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christophe DUMEZ (hydr0g3n) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copytree debug message problem Initial Comment: I noticed a problem in shutil.copytree : try: if symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): copytree(srcname, dstname, symlinks) else: copy2(srcname, dstname) # XXX What about devices, sockets etc.? except (IOError, os.error), why: errors.append((srcname, dstname, why)) 'why' isn't displayed in tuple, maybe this line would be better for debug : "errors.append((srcname, dstname, why.strerror))" then, it will display something (for example: 'permission denied'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472949&group_id=5470 From noreply at sourceforge.net Wed Apr 19 16:12:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 07:12:46 -0700 Subject: [ python-Bugs-1473000 ] valgrind detects problems in PyObject_Free Message-ID: Bugs item #1473000, was opened at 2006-04-19 14: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=1473000&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Jaime Torres Amate (jtajta2002) Assigned to: Nobody/Anonymous (nobody) Summary: valgrind detects problems in PyObject_Free Initial Comment: I just compiled python 2.4.3 with gcc 4.1.0, using glibc-2.4, and the COPTS = -g -O2 I just run valgrind (version 3.1.1) python -v And I get a lot of errors complaying about PyObject_Free: Conditional jump or move depends on uninitialised value(s) at 0x40B66A4: PyObject_Free (obmalloc.c:735) by 0x40B1E71: dictresize (dictobject.c:495) by 0x40B204D: PyDict_SetItemString (dictobject.c:1988) by 0x41048E3: Py_InitModule4 (modsupport.c:82) by 0x4116364: initposix (posixmodule.c:7895) by 0x40FF281: init_builtin (import.c:1765) by 0x40FF511: load_module (import.c:1694) by 0x40FFB3F: import_submodule (import.c:2266) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) ------------------------ Invalid read of size 4 at 0x40B669F: PyObject_Free (obmalloc.c:735) by 0x4103B7E: PyMarshal_ReadLastObjectFromFile (marshal.c:768) by 0x40FCE53: read_compiled_module (import.c:723) by 0x40FED89: load_source_module (import.c:891) by 0x40FFB3F: import_submodule (import.c:2266) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x408BB36: PyObject_Call (abstract.c:1795) by 0x40E580A: PyEval_CallObjectWithKeywords (ceval.c:3430) by 0x40E87D1: PyEval_EvalFrame (ceval.c:2020) Address 0x4339010 is 232 bytes inside a block of size 352 free'd at 0x4022E9D: free (vg_replace_malloc.c:235) by 0x41FBD1B: __fopen_internal (in /lib/libc-2.4.so) by 0x41FE569: fopen64 (in /lib/libc-2.4.so) by 0x40FD626: find_module (import.c:1316) by 0x40FFC64: import_submodule (import.c:2256) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x408BB36: PyObject_Call (abstract.c:1795) by 0x40E580A: PyEval_CallObjectWithKeywords (ceval.c:3430) by 0x40E87D1: PyEval_EvalFrame (ceval.c:2020) --------------------- Invalid read of size 4 at 0x40B669F: PyObject_Free (obmalloc.c:735) by 0x4085A12: PyGrammar_RemoveAccelerators (acceler.c:47) by 0x41070DC: Py_Finalize (pythonrun.c:436) by 0x410E2C4: Py_Main (main.c:513) by 0x8048559: main (in /usr/bin/python) Address 0x4364010 is 104 bytes inside a block of size 640 free'd at 0x4022E9D: free (vg_replace_malloc.c:235) by 0x40B66C0: PyObject_Free (obmalloc.c:798) by 0x4085BA1: PyGrammar_AddAccelerators (acceler.c:124) by 0x40866A7: PyParser_New (parser.c:77) by 0x4086722: parsetok (parsetok.c:109) by 0x4086C9E: PyParser_ParseStringFlags (parsetok.c:31) by 0x4105FF3: PyParser_SimpleParseStringFlags (pythonrun.c:1365) by 0x410644A: PyRun_StringFlags (pythonrun.c:1222) by 0x40E1CBA: builtin_eval (bltinmodule.c:527) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x40EAE9B: PyEval_EvalFrame (ceval.c:3563) by 0x40EA6AA: PyEval_EvalFrame (ceval.c:3645) -------------- ERROR SUMMARY: 9678 errors from 111 contexts (suppressed: 36 from 1) malloc/free: in use at exit: 715,180 bytes in 251 blocks. malloc/free: 1,822 allocs, 1,571 frees, 1,552,763 bytes allocated. For counts of detected errors, rerun with: -v searching for pointers to 251 not-freed blocks. checked 664,740 bytes. LEAK SUMMARY: definitely lost: 10 bytes in 2 blocks. possibly lost: 0 bytes in 0 blocks. still reachable: 715,170 bytes in 249 blocks. suppressed: 0 bytes in 0 blocks. Best regards and many thanks for such an incredible language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473000&group_id=5470 From noreply at sourceforge.net Wed Apr 19 16:44:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 07:44:18 -0700 Subject: [ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse Message-ID: Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-04-19 10:44 Message: Logged In: YES user_id=1344176 Aha. In which case, I'll work up a patch for the docs instead. Thanks for the clairification. I'll go ahead and close this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-19 00:42 Message: Logged In: YES user_id=31435 It doesn't really matter: self->key is either NULL or a Python string object, and neither can be involved in a cycle, so for purposes of cyclic gc it's just a waste of time to pass the key to a visit() callback. The docs could be clearer about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 From noreply at sourceforge.net Wed Apr 19 16:45:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 07:45:06 -0700 Subject: [ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse Message-ID: Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 Please note that this 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: Not a Bug >Status: Deleted >Resolution: Invalid Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-19 10:44 Message: Logged In: YES user_id=1344176 Aha. In which case, I'll work up a patch for the docs instead. Thanks for the clairification. I'll go ahead and close this report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-19 00:42 Message: Logged In: YES user_id=31435 It doesn't really matter: self->key is either NULL or a Python string object, and neither can be involved in a cycle, so for purposes of cyclic gc it's just a waste of time to pass the key to a visit() callback. The docs could be clearer about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 From noreply at sourceforge.net Wed Apr 19 17:45:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 08:45:24 -0700 Subject: [ python-Bugs-1473048 ] SimpleXMLRPCServer responds to any path Message-ID: Bugs item #1473048, was opened at 2006-04-19 11: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=1473048&group_id=5470 Please note that this 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 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer responds to any path Initial Comment: SimpleXMLRPCServer and DocXMLRPCServer don't look at the path of the HTTP request at all; you can POST or GET from / or /RPC2 or /blahblahblah with the same results. One minor problem with this liberality is that a security scanner that looks for vulnerable scripts such as /cgi-bin/phf will report the server as vulnerable. Nessus, for example, reports dozens of security holes on a SimpleXMLRPCServer for this reason. Fix: add a check that only allows '/' or '/RPC2' (maybe just /RPC2?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470 From noreply at sourceforge.net Wed Apr 19 19:16:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Apr 2006 10:16:11 -0700 Subject: [ python-Bugs-1472566 ] import module with .dll extension Message-ID: Bugs item #1472566, was opened at 2006-04-18 16:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 Please note that this 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 Submitted By: svenn (sven_nystrom) Assigned to: Martin v. L??wis (loewis) Summary: import module with .dll extension Initial Comment: In previous versions, extension modules with the file extension '.dll' could be imported using a single 'import' statement. In 2.5a1 this seems to have changed - here's an example: >>> import minx # Implemented in a .dll - fails Traceback (most recent call last): File "", line 1, in ImportError: No module named minx >>> import imp # Workaround >>> import os >>> minx = imp.load_dynamic('minx', os.getcwd() + '\\minx.dll') I would really like this to remain the same; if that's not possible, it would be helpful if the change itself and a suggested approach were to be included in the documentation. /Sven ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-19 13:16 Message: Logged In: YES user_id=31435 Note that rev 43622 added a comment to dynload_win.c explaining why it was done: """ /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll and the sqlite3 package. If this needs to be reverted for 2.5, some other solution for the naming conflict must be found. """ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 03:13 Message: Logged In: YES user_id=33168 I believe this was an intentional change in rev 43622. I don't see any doc associated with the change however. I also thought it was mentioned on python-dev. Martin, shouldn't this be documented at least in Misc/NEWS? I couldn't find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 From noreply at sourceforge.net Thu Apr 20 16:02:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 07:02:58 -0700 Subject: [ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given Message-ID: Bugs item #1473560, was opened at 2006-04-20 17: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=1473560&group_id=5470 Please note that this 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 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.Request constructor to urllib.quote the url given Initial Comment: urllib2.Request('http://www.google.com/search?client=firefox&q=foo bar', None) this fails. it shouldn't ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 From noreply at sourceforge.net Thu Apr 20 17:25:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 08:25:57 -0700 Subject: [ python-Bugs-1473625 ] cPickle produces locale-dependent dumps Message-ID: Bugs item #1473625, was opened at 2006-04-20 17: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=1473625&group_id=5470 Please note that this 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 Submitted By: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle produces locale-dependent dumps Initial Comment: Dumping a float with cPickle produces a result which is locale-dependent. This causes problems when trying to load the dump under a different locale (the regular pickle module is not affected by this bug). IMHO, the dump should be locale-independent to ensure portability. See the attached file for a sample session log showing the behaviour of both pickle and cPickle under C and ca_ES.UTF-8 locales (Catalan uses a comma to separate the integer and decimal part). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 From noreply at sourceforge.net Thu Apr 20 17:28:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 08:28:54 -0700 Subject: [ python-Bugs-1473625 ] cPickle produces locale-dependent dumps Message-ID: Bugs item #1473625, was opened at 2006-04-20 17:25 Message generated for change (Comment added) made by ivilata You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 Please note that this 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 Submitted By: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle produces locale-dependent dumps Initial Comment: Dumping a float with cPickle produces a result which is locale-dependent. This causes problems when trying to load the dump under a different locale (the regular pickle module is not affected by this bug). IMHO, the dump should be locale-independent to ensure portability. See the attached file for a sample session log showing the behaviour of both pickle and cPickle under C and ca_ES.UTF-8 locales (Catalan uses a comma to separate the integer and decimal part). ---------------------------------------------------------------------- >Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-04-20 17:28 Message: Logged In: YES user_id=1064183 As a side note, does this have anything to do with PEP 311? http://www.python.org/dev/peps/pep-0331/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 From noreply at sourceforge.net Thu Apr 20 20:35:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 11:35:21 -0700 Subject: [ python-Bugs-1473760 ] TempFile can hang on Windows Message-ID: Bugs item #1473760, was opened at 2006-04-20 14: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=1473760&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: TempFile can hang on Windows Initial Comment: Attached is a simple module. If you try to import it ("import hang"), it prints "asking for temp file", and hangs there, never returning from its call to tempfile.TemporaryFile(). It's in fact stuck in ntpath.py, on the "from nt import _getfullpathname" line in function `abspath`. Of course hang.py spawns another thread, and is hung waiting for the import lock. That thread isn't doing any imports the _user_ knows about, and Python's standard library should be coded more defensively than this. The symptom was reported on zodb-dev today, where Martin Gfeller reported ZEO hanging on Windows for what appears to be the same reason: http://mail.zope.org/pipermail/zodb-dev/2006-April/009989.html As it says there, it looks like this problem was introduced (indirectly) by patch http://www.python.org/sf/810914 which appears to have been revision 34396 (October 2003! -- but not backported to 2.3, so nobody would notice this before 2.4). I haven't dug deeper than this, and don't know why nobody noticed ZEO hanging before ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470 From noreply at sourceforge.net Thu Apr 20 23:54:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 14:54:44 -0700 Subject: [ python-Bugs-1473625 ] cPickle produces locale-dependent dumps Message-ID: Bugs item #1473625, was opened at 2006-04-20 17:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 Please note that this 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 Submitted By: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle produces locale-dependent dumps Initial Comment: Dumping a float with cPickle produces a result which is locale-dependent. This causes problems when trying to load the dump under a different locale (the regular pickle module is not affected by this bug). IMHO, the dump should be locale-independent to ensure portability. See the attached file for a sample session log showing the behaviour of both pickle and cPickle under C and ca_ES.UTF-8 locales (Catalan uses a comma to separate the integer and decimal part). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-20 23:54 Message: Logged In: YES user_id=21627 Right, cPickle should use C locale floating point numbers, using the PEP 331 API. Would you like to investigate a patch? ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-04-20 17:28 Message: Logged In: YES user_id=1064183 As a side note, does this have anything to do with PEP 311? http://www.python.org/dev/peps/pep-0331/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 From noreply at sourceforge.net Fri Apr 21 05:27:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 20:27:43 -0700 Subject: [ python-Bugs-1473979 ] test test_capi crashed -- thread.error: can't allocate lock Message-ID: Bugs item #1473979, was opened at 2006-04-21 10:27 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=1473979&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test test_capi crashed -- thread.error: can't allocate lock Initial Comment: Hi , This is shashikala . I am building Python 2.4.3 0n HP- UX 11.23 platform, the building of went smooth buit while testing Python using gmake test test_capi is failing . The Error is "test test_capi crashed -- thread.error: can't allocate lock" . Could you please help in fixing the above error. I am attaching the file which has details of the testing . Thanks and Regards, shashikala ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&group_id=5470 From noreply at sourceforge.net Fri Apr 21 05:29:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 20:29:26 -0700 Subject: [ python-Bugs-1471938 ] curses mvwgetnstr build problem on Solaris 8 Message-ID: Bugs item #1471938, was opened at 2006-04-17 20:07 Message generated for change (Comment added) made by eggert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: curses mvwgetnstr build problem on Solaris 8 Initial Comment: The _curses extension doesn't build on Solaris 8 (64-bit) due to the following problem: building '_curses' extension cc -O -xarch=v9 -xcode=pic32 -DNDEBUG -O -I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/./Include -I/u/cs/fac/eggert/seasnet/prefix/include -I./Include -I. -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Include -I/w/fac.01/cs/eggert/seasnet/Python-2.5a1 -c /w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c -o build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o "/w/fac.01/cs/eggert/seasnet/Python-2.5a1/Modules/_cursesmodule.c", line 822: warning: implicit function declaration: mvwgetnstr cc -O -xarch=v9 -G build/temp.solaris-2.8-sun4u-2.5/_cursesmodule.o -L/u/cs/fac/eggert/seasnet/prefix/lib -lcurses -ltermcap -o build/lib.solaris-2.8-sun4u-2.5/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.5/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension This problem occurs with both 2.4.3 and 2.5a1. I'll attach the obvious patch. ---------------------------------------------------------------------- >Comment By: Paul Eggert (eggert) Date: 2006-04-21 03:29 Message: Logged In: YES user_id=17848 Sorry, I'm trying again to attach a file now. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 22:53 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471938&group_id=5470 From noreply at sourceforge.net Fri Apr 21 05:50:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 20:50:42 -0700 Subject: [ python-Bugs-1473979 ] test test_capi crashed -- thread.error: can't allocate lock Message-ID: Bugs item #1473979, was opened at 2006-04-20 23:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test test_capi crashed -- thread.error: can't allocate lock Initial Comment: Hi , This is shashikala . I am building Python 2.4.3 0n HP- UX 11.23 platform, the building of went smooth buit while testing Python using gmake test test_capi is failing . The Error is "test test_capi crashed -- thread.error: can't allocate lock" . Could you please help in fixing the above error. I am attaching the file which has details of the testing . Thanks and Regards, shashikala ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-20 23:50 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&group_id=5470 From noreply at sourceforge.net Fri Apr 21 05:59:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 20:59:32 -0700 Subject: [ python-Bugs-1473000 ] valgrind detects problems in PyObject_Free Message-ID: Bugs item #1473000, was opened at 2006-04-19 07:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473000&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jaime Torres Amate (jtajta2002) >Assigned to: Neal Norwitz (nnorwitz) Summary: valgrind detects problems in PyObject_Free Initial Comment: I just compiled python 2.4.3 with gcc 4.1.0, using glibc-2.4, and the COPTS = -g -O2 I just run valgrind (version 3.1.1) python -v And I get a lot of errors complaying about PyObject_Free: Conditional jump or move depends on uninitialised value(s) at 0x40B66A4: PyObject_Free (obmalloc.c:735) by 0x40B1E71: dictresize (dictobject.c:495) by 0x40B204D: PyDict_SetItemString (dictobject.c:1988) by 0x41048E3: Py_InitModule4 (modsupport.c:82) by 0x4116364: initposix (posixmodule.c:7895) by 0x40FF281: init_builtin (import.c:1765) by 0x40FF511: load_module (import.c:1694) by 0x40FFB3F: import_submodule (import.c:2266) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) ------------------------ Invalid read of size 4 at 0x40B669F: PyObject_Free (obmalloc.c:735) by 0x4103B7E: PyMarshal_ReadLastObjectFromFile (marshal.c:768) by 0x40FCE53: read_compiled_module (import.c:723) by 0x40FED89: load_source_module (import.c:891) by 0x40FFB3F: import_submodule (import.c:2266) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x408BB36: PyObject_Call (abstract.c:1795) by 0x40E580A: PyEval_CallObjectWithKeywords (ceval.c:3430) by 0x40E87D1: PyEval_EvalFrame (ceval.c:2020) Address 0x4339010 is 232 bytes inside a block of size 352 free'd at 0x4022E9D: free (vg_replace_malloc.c:235) by 0x41FBD1B: __fopen_internal (in /lib/libc-2.4.so) by 0x41FE569: fopen64 (in /lib/libc-2.4.so) by 0x40FD626: find_module (import.c:1316) by 0x40FFC64: import_submodule (import.c:2256) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x408BB36: PyObject_Call (abstract.c:1795) by 0x40E580A: PyEval_CallObjectWithKeywords (ceval.c:3430) by 0x40E87D1: PyEval_EvalFrame (ceval.c:2020) --------------------- Invalid read of size 4 at 0x40B669F: PyObject_Free (obmalloc.c:735) by 0x4085A12: PyGrammar_RemoveAccelerators (acceler.c:47) by 0x41070DC: Py_Finalize (pythonrun.c:436) by 0x410E2C4: Py_Main (main.c:513) by 0x8048559: main (in /usr/bin/python) Address 0x4364010 is 104 bytes inside a block of size 640 free'd at 0x4022E9D: free (vg_replace_malloc.c:235) by 0x40B66C0: PyObject_Free (obmalloc.c:798) by 0x4085BA1: PyGrammar_AddAccelerators (acceler.c:124) by 0x40866A7: PyParser_New (parser.c:77) by 0x4086722: parsetok (parsetok.c:109) by 0x4086C9E: PyParser_ParseStringFlags (parsetok.c:31) by 0x4105FF3: PyParser_SimpleParseStringFlags (pythonrun.c:1365) by 0x410644A: PyRun_StringFlags (pythonrun.c:1222) by 0x40E1CBA: builtin_eval (bltinmodule.c:527) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x40EAE9B: PyEval_EvalFrame (ceval.c:3563) by 0x40EA6AA: PyEval_EvalFrame (ceval.c:3645) -------------- ERROR SUMMARY: 9678 errors from 111 contexts (suppressed: 36 from 1) malloc/free: in use at exit: 715,180 bytes in 251 blocks. malloc/free: 1,822 allocs, 1,571 frees, 1,552,763 bytes allocated. For counts of detected errors, rerun with: -v searching for pointers to 251 not-freed blocks. checked 664,740 bytes. LEAK SUMMARY: definitely lost: 10 bytes in 2 blocks. possibly lost: 0 bytes in 0 blocks. still reachable: 715,170 bytes in 249 blocks. suppressed: 0 bytes in 0 blocks. Best regards and many thanks for such an incredible language. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-20 20:59 Message: Logged In: YES user_id=33168 Please read this file: http://svn.python.org/projects/python/branches/release24-maint/Misc/README.valgrind That should explain what's going on and how to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473000&group_id=5470 From noreply at sourceforge.net Fri Apr 21 07:53:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 22:53:53 -0700 Subject: [ python-Bugs-1471806 ] IDLE does not start 2.4.3 Message-ID: Bugs item #1471806, was opened at 2006-04-17 08:58 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-20 22:53 Message: Logged In: YES user_id=341410 1. Start up a command line (Start -> Run -> cmd). 2. Change to the directory in which Python is installed (the following will likely work, if you installed Python using the default configuration)... c: cd \python24 3. Run idle from the command line... python lib\idlelib\idle.pyw Tell us what it prints out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 From noreply at sourceforge.net Fri Apr 21 07:59:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 22:59:20 -0700 Subject: [ python-Bugs-1471806 ] IDLE does not start 2.4.3 Message-ID: Bugs item #1471806, was opened at 2006-04-17 11:58 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2006-04-21 01:59 Message: Logged In: YES user_id=593130 I have opposite experience. Winxp home sp2, upgraded without uninstall. Did not turn off Win Firewall or AV. Idle 1.1.3 starts up nice as can be. File/Recent File list is still there. Opened one with test code and it just reran; all tests pass as did before with, I believe, same test report output. What happens when you open a Python command window? Have you run test/regrtest.py or anything else? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-21 01:53 Message: Logged In: YES user_id=341410 1. Start up a command line (Start -> Run -> cmd). 2. Change to the directory in which Python is installed (the following will likely work, if you installed Python using the default configuration)... c: cd \python24 3. Run idle from the command line... python lib\idlelib\idle.pyw Tell us what it prints out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 From noreply at sourceforge.net Fri Apr 21 08:03:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Apr 2006 23:03:27 -0700 Subject: [ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity Message-ID: Bugs item #1472695, was opened at 2006-04-19 01:10 Message generated for change (Comment added) made by pm67nz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 Please note that this 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 Submitted By: Peter Maxwell (pm67nz) Assigned to: Nobody/Anonymous (nobody) Summary: 32/64bit pickled Random incompatiblity Initial Comment: The unsigned long integers which make up the state of a Random instance are converted to Python integers via a cast to long in _randommodule.c's random_getstate function, so on a 32bit platform Random.getstate() returns a mix of postitive and negative integers, while on a 64bit platform the negative numbers are replaced by larger positive numbers, their 32bit-2s-complement equivalents. As a result, unpicking a Random instance from a 64bit machine on a 32bit platform produces the error "OverflowError: long int too large to convert to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the resulting object is in a slightly confused state: >>> r32 = cPickle.load(open('r32_3.pickle')) >>> for i in range(3): ... print r64.random(), r32.random() ... 0.237964627092 4292886520.32 0.544229225296 0.544229225296 0.369955166548 4292886520.19 ---------------------------------------------------------------------- >Comment By: Peter Maxwell (pm67nz) Date: 2006-04-21 06:03 Message: Logged In: YES user_id=320286 OK, here is a candidate patch, though I don't know if it is the best way to do it or meets the style guidelines etc. It makes Random pickles interchangable between 32bit and 64bit machines by encoding their states as Python long integers. An old pre-patch 32bit pickle loaded on a 64bit machine still fails (OverflowError: can't convert negative value to unsigned long) but I hope that combination is rare enough to ignore. Also on a 32bit machine new Random pickles can't be unpickled by a pre-patch python, but again there are limits to sane backward compatability. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 07:02 Message: Logged In: YES user_id=33168 Peter, thanks for the report. Do you think you could work up a patch to correct this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 From noreply at sourceforge.net Fri Apr 21 11:42:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 02:42:51 -0700 Subject: [ python-Bugs-1473625 ] cPickle produces locale-dependent dumps Message-ID: Bugs item #1473625, was opened at 2006-04-20 17:25 Message generated for change (Comment added) made by ivilata You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 Please note that this 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 Submitted By: Ivan Vilata i Balaguer (ivilata) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle produces locale-dependent dumps Initial Comment: Dumping a float with cPickle produces a result which is locale-dependent. This causes problems when trying to load the dump under a different locale (the regular pickle module is not affected by this bug). IMHO, the dump should be locale-independent to ensure portability. See the attached file for a sample session log showing the behaviour of both pickle and cPickle under C and ca_ES.UTF-8 locales (Catalan uses a comma to separate the integer and decimal part). ---------------------------------------------------------------------- >Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-04-21 11:42 Message: Logged In: YES user_id=1064183 The problem seems to be in save_float() in the cPickle.c module. It uses PyOS_snprintf() to dump floats, but it is locale-dependent. Fortunately, the PyOS_ascii_formatd() function can be used. The attached patch seems to fix the problem, and pickling tests run OK. It would be nice to see this patch applied to 2.4 also. (BTW, I meant PEP 331 in the previous comment, not 311, sorry.) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-20 23:54 Message: Logged In: YES user_id=21627 Right, cPickle should use C locale floating point numbers, using the PEP 331 API. Would you like to investigate a patch? ---------------------------------------------------------------------- Comment By: Ivan Vilata i Balaguer (ivilata) Date: 2006-04-20 17:28 Message: Logged In: YES user_id=1064183 As a side note, does this have anything to do with PEP 311? http://www.python.org/dev/peps/pep-0331/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473625&group_id=5470 From noreply at sourceforge.net Fri Apr 21 14:25:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 05:25:56 -0700 Subject: [ python-Bugs-1471806 ] IDLE does not start 2.4.3 Message-ID: Bugs item #1471806, was opened at 2006-04-17 11:58 Message generated for change (Comment added) made by egrimes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 Please note that this 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.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens ---------------------------------------------------------------------- >Comment By: Erin (egrimes) Date: 2006-04-21 08:25 Message: Logged In: YES user_id=1503943 When Python installed, my admin account was not given permission to access the C:\Documents and Settings\Admin\.idlerc folder which was preventing Python from starting. Thanks for showing me how to start IDLE in cmd prompt, that showed me the permission denied error on the folder. Might want to have python throw some sort of error if it tries to open via shortcut and that folder is blocked. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-04-21 01:59 Message: Logged In: YES user_id=593130 I have opposite experience. Winxp home sp2, upgraded without uninstall. Did not turn off Win Firewall or AV. Idle 1.1.3 starts up nice as can be. File/Recent File list is still there. Opened one with test code and it just reran; all tests pass as did before with, I believe, same test report output. What happens when you open a Python command window? Have you run test/regrtest.py or anything else? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-21 01:53 Message: Logged In: YES user_id=341410 1. Start up a command line (Start -> Run -> cmd). 2. Change to the directory in which Python is installed (the following will likely work, if you installed Python using the default configuration)... c: cd \python24 3. Run idle from the command line... python lib\idlelib\idle.pyw Tell us what it prints out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 From noreply at sourceforge.net Fri Apr 21 17:52:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 08:52:16 -0700 Subject: [ python-Bugs-1471806 ] IDLE does not start 2.4.3 Message-ID: Bugs item #1471806, was opened at 2006-04-17 08:58 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 Please note that this 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.4 Status: Closed Resolution: None Priority: 5 Submitted By: Erin (egrimes) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start 2.4.3 Initial Comment: IDLE does not start. 2.4.3 Installed Python 2.4.3 on Windows XP SP 2 I shutoff my ZoneAlarm Firewall and Stopped the Windows Firewall, turned off all Anti-Virus services. Python was 2.4.2 was previously installed on this machine and worked fine. Machine was wiped, reloaded and Python 2.4.3 was available. Steps: 1. Click Start -> All Programs -> Python 2.4 -> IDLE (Python GUI) 2. pythonw.exe process starts for a few seconds, then stops 3. Nothing happens ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-21 08:52 Message: Logged In: YES user_id=341410 A patch which offers such functionality would surely be appreciated. ---------------------------------------------------------------------- Comment By: Erin (egrimes) Date: 2006-04-21 05:25 Message: Logged In: YES user_id=1503943 When Python installed, my admin account was not given permission to access the C:\Documents and Settings\Admin\.idlerc folder which was preventing Python from starting. Thanks for showing me how to start IDLE in cmd prompt, that showed me the permission denied error on the folder. Might want to have python throw some sort of error if it tries to open via shortcut and that folder is blocked. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-04-20 22:59 Message: Logged In: YES user_id=593130 I have opposite experience. Winxp home sp2, upgraded without uninstall. Did not turn off Win Firewall or AV. Idle 1.1.3 starts up nice as can be. File/Recent File list is still there. Opened one with test code and it just reran; all tests pass as did before with, I believe, same test report output. What happens when you open a Python command window? Have you run test/regrtest.py or anything else? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-04-20 22:53 Message: Logged In: YES user_id=341410 1. Start up a command line (Start -> Run -> cmd). 2. Change to the directory in which Python is installed (the following will likely work, if you installed Python using the default configuration)... c: cd \python24 3. Run idle from the command line... python lib\idlelib\idle.pyw Tell us what it prints out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471806&group_id=5470 From noreply at sourceforge.net Fri Apr 21 18:41:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 09:41:06 -0700 Subject: [ python-Bugs-1350060 ] built-in method .__cmp__ Message-ID: Bugs item #1350060, was opened at 2005-11-07 08:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 Please note that this 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 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: built-in method .__cmp__ Initial Comment: Bound methods of built-in objects have a strange __cmp__/__hash__ combination: they compare equal only if their __self__ are identical, but they hash based on the hash of __self__ instead of its _Py_HashPointer(). Built-in methods should consistently be based on the identity *or* the equality of __self__. For reference, regular instance methods are based on the equality. So I propose to fix built-in method objects in the same way. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-04-21 16:41 Message: Logged In: YES user_id=4771 I've just been bitten by this problem. It's an arguably reasonable use case about why instance methods should work like immutable containers (they are immutable, after all) in the sense that equality should be structural. If nobody object I will check in a fix that makes instance methods and built-in instance methods compare their 'self' recursively. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:40 Message: Logged In: YES user_id=4771 Sorry, my mistake: regular instance methods behave like built-in methods. They are both based on the identity of their 'self' but use its hash to compute their own hash. This bug report is thus only about why should the hash of methods and built-in methods depend on the hash of their 'self'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 From noreply at sourceforge.net Fri Apr 21 19:01:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 10:01:24 -0700 Subject: [ python-Bugs-1409460 ] email.Utils.parseaddr() gives arcane result Message-ID: Bugs item #1409460, was opened at 2006-01-18 14:19 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470 Please note that this 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 Submitted By: Mark Sapiro (msapiro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Utils.parseaddr() gives arcane result Initial Comment: email.Utils.parseaddr('Real Name ((comment)) ') returns ('comment ', 'Real') Granted the string above is invalid as RFC 2822 does not allow parentheses within comments, but most mail agents seem to at least take the contents of the angle brackets as the address in this case. rfc822.parseaddr() returns the same result in this case. If these functions aren't going to return their respective failure indication in this case, I think they should at least return 'addr... at example.com' as the second item of the returned tuple. Note that parseaddr('Real Name ((comment))') does return ('Real Name', 'addr... at example.com') as 'expected'. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-21 10:01 Message: Logged In: YES user_id=1123998 It looks like this is addressed by patch 1464708 http://sourceforge.net/tracker/index.php?func=detail&aid=1464708&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470 From noreply at sourceforge.net Fri Apr 21 19:22:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 10:22:25 -0700 Subject: [ python-Bugs-1473760 ] TempFile can hang on Windows Message-ID: Bugs item #1473760, was opened at 2006-04-20 18:35 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: TempFile can hang on Windows Initial Comment: Attached is a simple module. If you try to import it ("import hang"), it prints "asking for temp file", and hangs there, never returning from its call to tempfile.TemporaryFile(). It's in fact stuck in ntpath.py, on the "from nt import _getfullpathname" line in function `abspath`. Of course hang.py spawns another thread, and is hung waiting for the import lock. That thread isn't doing any imports the _user_ knows about, and Python's standard library should be coded more defensively than this. The symptom was reported on zodb-dev today, where Martin Gfeller reported ZEO hanging on Windows for what appears to be the same reason: http://mail.zope.org/pipermail/zodb-dev/2006-April/009989.html As it says there, it looks like this problem was introduced (indirectly) by patch http://www.python.org/sf/810914 which appears to have been revision 34396 (October 2003! -- but not backported to 2.3, so nobody would notice this before 2.4). I haven't dug deeper than this, and don't know why nobody noticed ZEO hanging before ;-) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-04-21 17:22 Message: Logged In: YES user_id=4771 The general problem keeps showing up again and again. I can't find all reference (I remember more), but there are at least the following open bugs about it: #689895 #683658 #1175194. It would certainly help matters if we implemented something along the lines of putting a recursive lock on each module object, held while this specific module is being imported. More advanced solutions are possible too, but possibly more disruptive compatibility-wise... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470 From noreply at sourceforge.net Fri Apr 21 20:20:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 11:20:30 -0700 Subject: [ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers Message-ID: Bugs item #1470422, was opened at 2006-04-14 15:48 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 Please note that this 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 Submitted By: Michael Tsai (michaeltsai) >Assigned to: Vinay Sajip (vsajip) Summary: Logging doesn't report the correct filename or line numbers Initial Comment: I have a logger that prints out %(filename)s:%(lineno)d along with the message. Instead of printing the file and line in my code where I call the logger, it prints out a location in logging/__init__.py. I was able to fix this, at least for my purposes, by changing logging.currentframe from sys._getframe to lambda:sys._getframe(3). ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-04-21 18:20 Message: Logged In: YES user_id=308438 Please can you provide a small script which demonstrates the problem? Which platform are you running on? Is there anything unusual about your setup (e.g. running from a frozen system)? I'm not sure your patch is the correct solution. The system looks up the call stack until a file is found which is not the source file of the logging module itself - that is presumed to be the caller. However, determining the source file of the logging module can come unstuck in scenarios such as py2exe-ified programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 From noreply at sourceforge.net Fri Apr 21 21:04:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 12:04:20 -0700 Subject: [ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers Message-ID: Bugs item #1470422, was opened at 2006-04-14 11:48 Message generated for change (Comment added) made by michaeltsai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 Please note that this 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 Submitted By: Michael Tsai (michaeltsai) Assigned to: Vinay Sajip (vsajip) Summary: Logging doesn't report the correct filename or line numbers Initial Comment: I have a logger that prints out %(filename)s:%(lineno)d along with the message. Instead of printing the file and line in my code where I call the logger, it prints out a location in logging/__init__.py. I was able to fix this, at least for my purposes, by changing logging.currentframe from sys._getframe to lambda:sys._getframe(3). ---------------------------------------------------------------------- >Comment By: Michael Tsai (michaeltsai) Date: 2006-04-21 15:04 Message: Logged In: YES user_id=817528 I'm running on Mac OS X 10.4.6. Here's a simple script: """#!/usr/local/bin/python2.4 import logging logging.basicConfig(format=u"%(filename)s:%(lineno)d %(message)s") log = logging.getLogger("test") log.error(u"this is an error") """ Unfortunately, it doesn't reliably fail; most of the time it works. I haven't figured out how to trigger it. It does reliably fail when I use a frozen system created with "py2app -A" in which the Python libraries are symlinked in (rather than in a Zip). Then, logging._srcfile is "logging/__init__.py", but __file__ is something like "/ System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ logging/__init__.py" Maybe py2app shouldn't set sys.frozen in this case? Anyway, I don't think that's the real problem, because I've seen this happen when not using py2app (but, sorry, I'm not able to reliably duplicate it at this time). My patch isn't really the right fix, but I do think it works because, at least with the current logging module, currentframe() is always called with the same sequence of frames on the top of the stack. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-04-21 14:20 Message: Logged In: YES user_id=308438 Please can you provide a small script which demonstrates the problem? Which platform are you running on? Is there anything unusual about your setup (e.g. running from a frozen system)? I'm not sure your patch is the correct solution. The system looks up the call stack until a file is found which is not the source file of the logging module itself - that is presumed to be the caller. However, determining the source file of the logging module can come unstuck in scenarios such as py2exe-ified programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 From noreply at sourceforge.net Fri Apr 21 23:26:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Apr 2006 14:26:22 -0700 Subject: [ python-Bugs-1473760 ] TempFile can hang on Windows Message-ID: Bugs item #1473760, was opened at 2006-04-20 14:35 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470 Please note that this 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: 7 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: TempFile can hang on Windows Initial Comment: Attached is a simple module. If you try to import it ("import hang"), it prints "asking for temp file", and hangs there, never returning from its call to tempfile.TemporaryFile(). It's in fact stuck in ntpath.py, on the "from nt import _getfullpathname" line in function `abspath`. Of course hang.py spawns another thread, and is hung waiting for the import lock. That thread isn't doing any imports the _user_ knows about, and Python's standard library should be coded more defensively than this. The symptom was reported on zodb-dev today, where Martin Gfeller reported ZEO hanging on Windows for what appears to be the same reason: http://mail.zope.org/pipermail/zodb-dev/2006-April/009989.html As it says there, it looks like this problem was introduced (indirectly) by patch http://www.python.org/sf/810914 which appears to have been revision 34396 (October 2003! -- but not backported to 2.3, so nobody would notice this before 2.4). I haven't dug deeper than this, and don't know why nobody noticed ZEO hanging before ;-) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-21 17:26 Message: Logged In: YES user_id=31435 Fixed in rev 45631 on the trunk, and rev 45632 on the 2.4 branch. Armin, I agree this could use a better approach. I settled for a micro-fix here because this specific one accounts for a report of Zope Corp's ZEO hanging on Windows, and it was an odd way to change ntpath.abspath to begin with. Note that I added a new Lib/test/threaded_import_hangers.py to check that tempfile.TemporaryFile and os.path.abspath don't hang anymore, and that's designed to make it easy to add additional tests of this kind. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-21 13:22 Message: Logged In: YES user_id=4771 The general problem keeps showing up again and again. I can't find all reference (I remember more), but there are at least the following open bugs about it: #689895 #683658 #1175194. It would certainly help matters if we implemented something along the lines of putting a recursive lock on each module object, held while this specific module is being imported. More advanced solutions are possible too, but possibly more disruptive compatibility-wise... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473760&group_id=5470 From noreply at sourceforge.net Sat Apr 22 11:50:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 02:50:51 -0700 Subject: [ python-Feature Requests-1474577 ] feature requests for logging lib Message-ID: Feature Requests item #1474577, was opened at 2006-04-22 19:50 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=1474577&group_id=5470 Please note that this 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 Submitted By: blaize rhodes (blaize) Assigned to: Nobody/Anonymous (nobody) Summary: feature requests for logging lib Initial Comment: The logger module interface is a bit broken, I reckon. My problems specifically are: i) It's hard to get access to the LogRecord classes for customization. ii) the semantics of the debug, log, info, etc calls is a bit strange/confusing... Here are my proposed fixes: a) Add a method Logger.setLogRecordClass( myLogRecordSubClass ) which sets the class that is instantiated in the makeRecord() fn/method (yes there are two of them). This would make customizing the LogRecord easier... Otherwise (I believe) in order to subclass the LogRecord you also have to overload the Logger and possibly the root makeRecord() function as well? This bloke's writen up his approach to this (it's doable but not as nice as it should be). http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html Another problem is that LogRecords are instantiated in Logger._log so it's difficult to customize __init__ behaviour for the LogRecord (and I argue that this is a useful thing).. b) A second problem is that the semantics of the log, info, debug, etc fns is a bit broken. Currently the defn looks like this: def debug(self, msg, *args, **kwargs): this suggests to me that a call like this is OK... logger.debug("here we go %(foo)s", foo = 'bar') but it's not. This is discussed further here... http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881 Instead kwargs are used for customizing the behaviour of the debug method (e.g. exc_info, and extra). This seems i) a bit incongrous with its definition and therefore confusing, and ii) a bit of a hack (it's not completely insane though when you think about what's happening under the hood). Instead I propose using a couple of calls along the lines of printf/fprintf. In my world we'd have a simple printf-style function... def debug(self, msg, *args): and a more complex, more easily customizable fprintf-style one def x_debug(self, log_record, msg, *args): In these calls *args is a valid argument for the string formatting operator %, either a tuple of the right length or a dictionary. Any customization of the behaviour of the system can be done (using keyword args if you wish) in the log_record initializer (an example will follow). (Having said that perhaps we can check whether the first arg to the new simple debug() is a logrecord and if it is call the (hidden) extended version - that's more pythonic I imagine) c) This is not so much a feature request but a motivating mode of operation that I'd like to be able to use... Currently you can set up log filters. What you can filter is largely based on what information appears in the log record. It'd be nice to filter messages based on metadata that you add at log time (i.e. in the logger.debug(...) method). Currently it's quite painfull to set this up. This is because we can't customize the initialization of the log_record. The call structure in ii) above allows us to setup nice filtering mechanisms eg.. class GUIFilter: "A filter that only lets messges with gui tags through.""" def filter(self, log_record): return hasattr(log_record, 'gui') # set up a log, and a handler... log = logging.getLogger(..) file_handler = FileHandler(..) log.addHandler(file_handler) gui_msg_bar_handler = StreamHandler(..) log.addHandler(gui_msg_bar_handler) gui_msg_bar_handler.addFilter(GUIFilter()) # msg only goes to the file_handler log.debug("here we go %s", "here's an arg") # msg goes to the file_handler and to the gui_handler. log.x_debug(LogRecord(gui=True), "what you just tried to do didn't work %s", "fool") Change a) could be made with no backward compatability problems (I can see), change b) could be made without probs if you didn't overload the existing logging methods with the new ones, and then deprecate the existing ones (though what you'd call the new fns I don't know). That said I quite like the logger lib and I use it. It's a lot better than anything I would have thought up. cheers blaize ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470 From noreply at sourceforge.net Sat Apr 22 11:56:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 02:56:51 -0700 Subject: [ python-Feature Requests-1474577 ] feature requests for logging lib Message-ID: Feature Requests item #1474577, was opened at 2006-04-22 19:50 Message generated for change (Comment added) made by blaize You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470 Please note that this 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 Submitted By: blaize rhodes (blaize) Assigned to: Nobody/Anonymous (nobody) Summary: feature requests for logging lib Initial Comment: The logger module interface is a bit broken, I reckon. My problems specifically are: i) It's hard to get access to the LogRecord classes for customization. ii) the semantics of the debug, log, info, etc calls is a bit strange/confusing... Here are my proposed fixes: a) Add a method Logger.setLogRecordClass( myLogRecordSubClass ) which sets the class that is instantiated in the makeRecord() fn/method (yes there are two of them). This would make customizing the LogRecord easier... Otherwise (I believe) in order to subclass the LogRecord you also have to overload the Logger and possibly the root makeRecord() function as well? This bloke's writen up his approach to this (it's doable but not as nice as it should be). http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html Another problem is that LogRecords are instantiated in Logger._log so it's difficult to customize __init__ behaviour for the LogRecord (and I argue that this is a useful thing).. b) A second problem is that the semantics of the log, info, debug, etc fns is a bit broken. Currently the defn looks like this: def debug(self, msg, *args, **kwargs): this suggests to me that a call like this is OK... logger.debug("here we go %(foo)s", foo = 'bar') but it's not. This is discussed further here... http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881 Instead kwargs are used for customizing the behaviour of the debug method (e.g. exc_info, and extra). This seems i) a bit incongrous with its definition and therefore confusing, and ii) a bit of a hack (it's not completely insane though when you think about what's happening under the hood). Instead I propose using a couple of calls along the lines of printf/fprintf. In my world we'd have a simple printf-style function... def debug(self, msg, *args): and a more complex, more easily customizable fprintf-style one def x_debug(self, log_record, msg, *args): In these calls *args is a valid argument for the string formatting operator %, either a tuple of the right length or a dictionary. Any customization of the behaviour of the system can be done (using keyword args if you wish) in the log_record initializer (an example will follow). (Having said that perhaps we can check whether the first arg to the new simple debug() is a logrecord and if it is call the (hidden) extended version - that's more pythonic I imagine) c) This is not so much a feature request but a motivating mode of operation that I'd like to be able to use... Currently you can set up log filters. What you can filter is largely based on what information appears in the log record. It'd be nice to filter messages based on metadata that you add at log time (i.e. in the logger.debug(...) method). Currently it's quite painfull to set this up. This is because we can't customize the initialization of the log_record. The call structure in ii) above allows us to setup nice filtering mechanisms eg.. class GUIFilter: "A filter that only lets messges with gui tags through.""" def filter(self, log_record): return hasattr(log_record, 'gui') # set up a log, and a handler... log = logging.getLogger(..) file_handler = FileHandler(..) log.addHandler(file_handler) gui_msg_bar_handler = StreamHandler(..) log.addHandler(gui_msg_bar_handler) gui_msg_bar_handler.addFilter(GUIFilter()) # msg only goes to the file_handler log.debug("here we go %s", "here's an arg") # msg goes to the file_handler and to the gui_handler. log.x_debug(LogRecord(gui=True), "what you just tried to do didn't work %s", "fool") Change a) could be made with no backward compatability problems (I can see), change b) could be made without probs if you didn't overload the existing logging methods with the new ones, and then deprecate the existing ones (though what you'd call the new fns I don't know). That said I quite like the logger lib and I use it. It's a lot better than anything I would have thought up. cheers blaize ---------------------------------------------------------------------- >Comment By: blaize rhodes (blaize) Date: 2006-04-22 19:56 Message: Logged In: YES user_id=264689 For readability put an "if __name__ == '__main__':" above the # set up a log, and a handler... line. Sorry I didn't realize all my whitespace would get eaten rendering the code ambiguous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470 From noreply at sourceforge.net Sat Apr 22 14:02:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 05:02:18 -0700 Subject: [ python-Feature Requests-1474609 ] feature requests for logging lib Message-ID: Feature Requests item #1474609, was opened at 2006-04-22 22:02 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=1474609&group_id=5470 Please note that this 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 Submitted By: blaize rhodes (blaize) Assigned to: Nobody/Anonymous (nobody) Summary: feature requests for logging lib Initial Comment: The logger module interface is a bit broken, I reckon. My problems specifically are: i) It's hard to get access to the LogRecord classes for customization. ii) the semantics of the debug, log, info, etc calls is a bit strange/confusing... Here are my proposed fixes: a) Add a method Logger.setLogRecordClass( myLogRecordSubClass ) which sets the class that is instantiated in the makeRecord() fn/method (yes there are two of them). This would make customizing the LogRecord easier... Otherwise (I believe) in order to subclass the LogRecord you also have to overload the Logger and possibly the root makeRecord() function as well? This bloke's writen up his approach to this (it's doable but not as nice as it should be). http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html Another problem is that LogRecords are instantiated in Logger._log so it's difficult to customize __init__ behaviour for the LogRecord (and I argue that this is a useful thing).. b) A second problem is that the semantics of the log, info, debug, etc fns is a bit broken. Currently the defn looks like this: def debug(self, msg, *args, **kwargs): this suggests to me that a call like this is OK... logger.debug("here we go %(foo)s", foo = 'bar') but it's not. This is discussed further here... http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881 Instead kwargs are used for customizing the behaviour of the debug method (e.g. exc_info, and extra). This seems i) a bit incongrous with its definition and therefore confusing, and ii) a bit of a hack (it's not completely insane though when you think about what's happening under the hood). Instead I propose using a couple of calls along the lines of printf/fprintf. In my world we'd have a simple printf-style function... def debug(self, msg, *args): and a more complex, more easily customizable fprintf-style one def x_debug(self, log_record, msg, *args): In these calls *args is a valid argument for the string formatting operator %, either a tuple of the right length or a dictionary. Any customization of the behaviour of the system can be done (using keyword args if you wish) in the log_record initializer (an example will follow). (Having said that perhaps we can check whether the first arg to the new simple debug() is a logrecord and if it is call the (hidden) extended version - that's more pythonic I imagine) c) This is not so much a feature request but a motivating mode of operation that I'd like to be able to use... Currently you can set up log filters. What you can filter is largely based on what information appears in the log record. It'd be nice to filter messages based on metadata that you add at log time (i.e. in the logger.debug(...) method). Currently it's quite painfull to set this up. This is because we can't customize the initialization of the log_record. The call structure in ii) above allows us to setup nice filtering mechanisms eg.. class GUIFilter: "A filter that only lets messges with gui tags through.""" def filter(self, log_record): return hasattr(log_record, 'gui') # set up a log, and a handler... log = logging.getLogger(..) file_handler = FileHandler(..) log.addHandler(file_handler) gui_msg_bar_handler = StreamHandler(..) log.addHandler(gui_msg_bar_handler) gui_msg_bar_handler.addFilter(GUIFilter()) # msg only goes to the file_handler log.debug("here we go %s", "here's an arg") # msg goes to the file_handler and to the gui_handler. log.x_debug(LogRecord(gui=True), "what you just tried to do didn't work %s", "fool") Change a) could be made with no backward compatability problems (I can see), change b) could be made without probs if you didn't overload the existing logging methods with the new ones, and then deprecate the existing ones (though what you'd call the new fns I don't know). That said I quite like the logger lib and I use it. It's a lot better than anything I would have thought up. cheers blaize ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474609&group_id=5470 From noreply at sourceforge.net Sat Apr 22 16:26:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 07:26:21 -0700 Subject: [ python-Bugs-1472566 ] import module with .dll extension Message-ID: Bugs item #1472566, was opened at 2006-04-18 22:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 Please note that this 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 Submitted By: svenn (sven_nystrom) Assigned to: Martin v. L??wis (loewis) Summary: import module with .dll extension Initial Comment: In previous versions, extension modules with the file extension '.dll' could be imported using a single 'import' statement. In 2.5a1 this seems to have changed - here's an example: >>> import minx # Implemented in a .dll - fails Traceback (most recent call last): File "", line 1, in ImportError: No module named minx >>> import imp # Workaround >>> import os >>> minx = imp.load_dynamic('minx', os.getcwd() + '\\minx.dll') I would really like this to remain the same; if that's not possible, it would be helpful if the change itself and a suggested approach were to be included in the documentation. /Sven ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-22 16:26 Message: Logged In: YES user_id=21627 Tim mentions the rationale for the change; the Misc/NEWS entry is now in r45574. svenn, why do you need it to work that way? Could you change your code/application/whatever so that it works with .pyd files instead? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-19 19:16 Message: Logged In: YES user_id=31435 Note that rev 43622 added a comment to dynload_win.c explaining why it was done: """ /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll and the sqlite3 package. If this needs to be reverted for 2.5, some other solution for the naming conflict must be found. """ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 09:13 Message: Logged In: YES user_id=33168 I believe this was an intentional change in rev 43622. I don't see any doc associated with the change however. I also thought it was mentioned on python-dev. Martin, shouldn't this be documented at least in Misc/NEWS? I couldn't find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 From noreply at sourceforge.net Sat Apr 22 18:11:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 09:11:44 -0700 Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword Message-ID: Bugs item #1474677, was opened at 2006-04-23 01:11 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=1474677&group_id=5470 Please note that this 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 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 From noreply at sourceforge.net Sat Apr 22 18:20:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 09:20:51 -0700 Subject: [ python-Bugs-1474680 ] pickling files works with protocol=2. Message-ID: Bugs item #1474680, was opened at 2006-04-22 19: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=1474680&group_id=5470 Please note that this 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 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: pickling files works with protocol=2. Initial Comment: Compare: >>> import pickle >>> pickle.dumps(file('/etc/passwd')) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "/usr/lib/python2.4/pickle.py", line 231, in dump self.save(obj) File "/usr/lib/python2.4/pickle.py", line 313, in save rv = reduce(self.proto) File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle file objects with >>> pickle.dumps(file('/etc/passwd'), protocol=2) '\x80\x02c__builtin__\nfile\nq\x00)\x81q\x01.' Similarly, the __reduce__ method works for basic objects like str, int or dict with protocol=2, but doesn't work with protocol=1: >>> (1).__reduce_ex__(1) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle int objects >>> (1).__reduce_ex__(2) (, (, 1), None, None, None) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474680&group_id=5470 From noreply at sourceforge.net Sat Apr 22 18:25:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 22 Apr 2006 09:25:38 -0700 Subject: [ python-Bugs-1472566 ] import module with .dll extension Message-ID: Bugs item #1472566, was opened at 2006-04-18 22:06 Message generated for change (Comment added) made by sven_nystrom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 Please note that this 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 Submitted By: svenn (sven_nystrom) Assigned to: Martin v. L??wis (loewis) Summary: import module with .dll extension Initial Comment: In previous versions, extension modules with the file extension '.dll' could be imported using a single 'import' statement. In 2.5a1 this seems to have changed - here's an example: >>> import minx # Implemented in a .dll - fails Traceback (most recent call last): File "", line 1, in ImportError: No module named minx >>> import imp # Workaround >>> import os >>> minx = imp.load_dynamic('minx', os.getcwd() + '\\minx.dll') I would really like this to remain the same; if that's not possible, it would be helpful if the change itself and a suggested approach were to be included in the documentation. /Sven ---------------------------------------------------------------------- >Comment By: svenn (sven_nystrom) Date: 2006-04-22 18:25 Message: Logged In: YES user_id=1504966 Hi loewis, I', sure the .pyd extension will work fine - my original comment was due to the fact I didn't realise it would work as today if the file extension was changed; I was (wrongly) assuming I would have to use the approach indicated in my example, which seemed a little less intuitive than the simple "import". ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-22 16:26 Message: Logged In: YES user_id=21627 Tim mentions the rationale for the change; the Misc/NEWS entry is now in r45574. svenn, why do you need it to work that way? Could you change your code/application/whatever so that it works with .pyd files instead? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-19 19:16 Message: Logged In: YES user_id=31435 Note that rev 43622 added a comment to dynload_win.c explaining why it was done: """ /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll and the sqlite3 package. If this needs to be reverted for 2.5, some other solution for the naming conflict must be found. """ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 09:13 Message: Logged In: YES user_id=33168 I believe this was an intentional change in rev 43622. I don't see any doc associated with the change however. I also thought it was mentioned on python-dev. Martin, shouldn't this be documented at least in Misc/NEWS? I couldn't find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 From noreply at sourceforge.net Sun Apr 23 15:08:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 06:08:24 -0700 Subject: [ python-Bugs-1475009 ] Document os.path.join oddity on Windows Message-ID: Bugs item #1475009, was opened at 2006-04-23 16: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=1475009&group_id=5470 Please note that this 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 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Document os.path.join oddity on Windows Initial Comment: Please document that on windows os.path.join("m:\\noo", "\\woo") => '\\woo' >From reading the code I see that this is intetional, however it need to be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&group_id=5470 From noreply at sourceforge.net Sun Apr 23 18:51:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 09:51:23 -0700 Subject: [ python-Bugs-1475080 ] example code in what's new/sqlite3 docs Message-ID: Bugs item #1475080, was opened at 2006-04-23 12: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=1475080&group_id=5470 Please note that this 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 Submitted By: James Pryor (jpryor68) Assigned to: Nobody/Anonymous (nobody) Summary: example code in what's new/sqlite3 docs Initial Comment: The documentation at contains the following example code: # Never do this -- insecure! symbol = 'IBM' c.execute("... where symbol = '%s'" % symbol) # Do this instead t = (symbol,) c.execute('select * from stocks where symbol=?', ('IBM',)) The second block should instead read: # Do this instead t = ('IBM',) c.execute('select * from stocks where symbol=?', t) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470 From noreply at sourceforge.net Sun Apr 23 19:38:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 10:38:28 -0700 Subject: [ python-Bugs-1475009 ] Document os.path.join oddity on Windows Message-ID: Bugs item #1475009, was opened at 2006-04-23 09:08 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&group_id=5470 Please note that this 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 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Document os.path.join oddity on Windows Initial Comment: Please document that on windows os.path.join("m:\\noo", "\\woo") => '\\woo' >From reading the code I see that this is intetional, however it need to be documented. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-23 13:38 Message: Logged In: YES user_id=31435 Noting that there's nothing special about Windows here: >>> import posixpath >>> posixpath.join('/noo', '/woo') '/woo' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&group_id=5470 From noreply at sourceforge.net Sun Apr 23 23:34:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 14:34:43 -0700 Subject: [ python-Bugs-1475162 ] Tkinter hangs in test_tcl Message-ID: Bugs item #1475162, was opened at 2006-04-23 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=1475162&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Martin v. L??wis (loewis) Summary: Tkinter hangs in test_tcl Initial Comment: For a while now, I've noticed test_tcl locking up when trying to refleaktest it. I was able to reproduce it quite simply: import Tkinter, os if "DISPLAY" in os.environ: del os.environ["DISPLAY"] tcl = Tkinter.Tcl() try: tcl.loadtk() except Exception, e: print e tcl.loadtk() Or using _tkinter directly: import _tkinter, os if "DISPLAY" in os.environ: del os.environ["DISPLAY"] tk = _tkinter.create(None, "test", "Tk", 0, 1, 0) try: tk.loadtk() except: pass tk.loadtk() In either case, the second loadtk never finishes. It seems that, on my platform at least, Tk_Init() doesn't like being called twice even when the first call resulted in an error. That's Tcl and Tk 8.4.12. Tkapp_Init() (which is the Tkinter part that calls Tk_Init()) does its best to guard against calling Tk_Init() twice when the first call was succesful, but it doesn't remember failure cases. I don't know enough about Tcl/Tk or Tkinter to know how this is best handled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475162&group_id=5470 From noreply at sourceforge.net Mon Apr 24 00:49:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 15:49:38 -0700 Subject: [ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Message-ID: Bugs item #1472173, was opened at 2006-04-18 11:20 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-24 00:49 Message: Logged In: YES user_id=34209 Closing as fixed then :) ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-04-19 11:11 Message: Logged In: YES user_id=972995 oops, is ok after: apt-get install libreadline5-dev ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 06:16 Message: Logged In: YES user_id=33168 Hmmm, it's possible some of the configure magic changed. It might have been inadvertant. Can you attach your config.log? When you did a ./configure it should have printed out some things about readline and searching for it. That might help you diagnose the problem. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-04-18 11:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 From noreply at sourceforge.net Mon Apr 24 03:19:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 18:19:04 -0700 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 10:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: Matt Fleming (splitscreen) >Assigned to: Georg Brandl (gbrandl) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-23 21:19 Message: Logged In: YES user_id=31435 This is still ;-) fine with me. There doesn't seem to be a test in fileobject2.diff. WRT the docs, "must either be" should say "must be one of" instead ("either" is proper for two choices, but there are three). It should state that this requirement is new in Python 2.5; in LaTeX, something like \versionchanged[Restriction on first letter of mode string introduced]{2.5} ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-12 06:14 Message: Logged In: YES user_id=1126061 Yeah, your patch looks much better. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 04:15 Message: Logged In: YES user_id=849994 splitscreen: your patch was incomplete and could have overwritten memory. tim_one: Attaching new patch implementing what I proposed in my comment below. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 16:59 Message: Logged In: YES user_id=1126061 Ok, uploading latest patch, not quite sure I've hit the mark here. Please review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 15:43 Message: Logged In: YES user_id=849994 Yes, I want to remove 'U' from the mode since it's at this point already recognized by Python, and it's not meaningful to the underlying C library. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 14:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 09:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 02:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 13:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Mon Apr 24 03:21:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 18:21:52 -0700 Subject: [ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters Message-ID: Bugs item #1293741, was opened at 2005-09-17 07:41 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: GRISEL (ogrisel) >Assigned to: Nobody/Anonymous (nobody) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-23 21:21 Message: Logged In: YES user_id=31435 Unassigned myself -- don't know enough about encodings. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2006-02-16 06:41 Message: Logged In: YES user_id=1032069 I'm quite sure that you can use non-ASCII characters in your doctest, given that it's a unicode string. So if you make your docstring a unicode string, it should work. That is: u"""Docstring containing non-ASCII characters. ... """ ---------------------------------------------------------------------- Comment By: GRISEL (ogrisel) Date: 2005-09-18 06:25 Message: Logged In: YES user_id=795041 Unfortunateny that patch does not fix my problem. The patch at bug #1080727 fixes the problem for doctests written in external reST files (testfile and DocFileTest functions). My problem is related to internal docstring encoding (testmod for instance). However, Bjorn Tillenius says: """ If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. """ So according to him, docstrings' doctests with non-ascii characters should work by default. So maybe my system setup is somewhat broken. Could somebody please confirm/infirm this by running the attached sample script on his system? My system config: LANG=fr_FR at euro (on linux) python 2.4.1 with: sys.getdefaultencoding() == 'ascii' and locale.getpreferredencoding() == 'ISO-8859-15' $ file test_iso-8859-15.py test_iso-8859-15.py: ISO-8859 English text ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-17 13:42 Message: Logged In: YES user_id=31435 Please try the patch at http://www.python.org/sf/1080727 and report back on whether it solves your problem (attaching comments to the patch report would be most useful). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 From noreply at sourceforge.net Mon Apr 24 03:26:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 18:26:25 -0700 Subject: [ python-Bugs-777597 ] socketmodule.c connection handling incorect on windows Message-ID: Bugs item #777597, was opened at 2003-07-25 11:01 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470 Please note that this 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 Submitted By: Garth Bushell (garth42) >Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c connection handling incorect on windows Initial Comment: The socketmodule.c code does not handle connection refused correctly. This is due to a different of operation on windows of select. The offending code is in internal_connect in the MS_WINDOWS ifdef. The code in should test exceptfds to check for connecttion refused. If this is so itshould call getsockopt(SOL_SOCKET, SO_ERROR,..) to get the error status. (Source microsoft Platform SDK) The suggested fix is shown below (untested) #ifdef MS_WINDOWS f (s->sock_timeout > 0.0) { if (res < 0 && WSAGetLastError() == WSAEWOULDBLOCK) { /* This is a mess. Best solution: trust select */ fd_set exfds; struct timeval tv; tv.tv_sec = (int)s->sock_timeout; tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6); FD_ZERO(&exfds); FD_SET(s->sock_fd, &exfds); /* Platform SDK says so */ res = select(s->sock_fd+1, NULL, NULL, &exfds, &tv); if (res > 0) { if( FD_ISSET( &exfds ) ) { /* Get the real reason */ getsockopt(s->sock_fd,SOL_SOCKET,SO_ERROR,(char*)&res,sizeof(res)); } else { /* God knows how we got here */ res = 0; } } else if( res == 0 ) { res = WSAEWOULDBLOCK; } else { /* Not sure we should return the erro from select? */ res = WSAGetLastError(); } } } else if (res < 0) res = WSAGetLastError(); #else ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-23 21:26 Message: Logged In: YES user_id=31435 Unassigned myself (no particular competence here, and short on time). ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-08 04:48 Message: Logged In: YES user_id=32863 http://python.org/sf/965036 has been updated with a fixed and tested patch. Could somebody review and apply it? Thanks! ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-02 09:59 Message: Logged In: YES user_id=32863 I have turned Garth's code into a patch versus Python 2.3.4. I don't believe the fix is correct and complete, but it should serve as a starting point. Patch is in http://python.org/sf/965036 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-28 18:00 Message: Logged In: YES user_id=33168 Garth could you produce a patch against 2.3c2 with your selected change and test it? It would help us a lot as we are all very overloaded. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470 From noreply at sourceforge.net Mon Apr 24 04:13:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Apr 2006 19:13:58 -0700 Subject: [ python-Bugs-1337990 ] doctest mishandles exceptions raised within generators Message-ID: Bugs item #1337990, was opened at 2005-10-25 22:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337990&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Tim Wegener (twegener) >Assigned to: Nobody/Anonymous (nobody) Summary: doctest mishandles exceptions raised within generators Initial Comment: If a generator raises an exception while iterating over it, doctest will only register the exception output, and will miss output that occurred during previous loop iterations. The following code clarifies and reproduces the problem: (also included as an attachment) """Reproduce bug with exceptions in a generator in doctest tests. This bug has been seen to occur in: Linux (RH9): Python 2.4.1 Python 2.3.5 Python 2.2.2 (using from __future__ import generators) Windows XP: Python 2.4.2 Python 2.3.5 """ def error_generator(): """Yield 0 to 2 and then try and raise an exception. >>> for j in error_generator(): ... print j 0 1 2 Traceback (most recent call last): Exception: Contrived exception for sake of example """ # Note: This is obviously a contrived example of generator use. for i in range(3): yield i if 1: raise Exception("Contrived exception for sake of example") raise StopIteration if __name__ == '__main__': # Run the doctest tests. import sys import doctest doctest.testmod(sys.modules['__main__']) print print 'What should have happened...' for j in error_generator(): print j ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-23 22:13 Message: Logged In: YES user_id=31435 doctest doesn't support mixing "expected normal output" with an exception, regardless of how such a thing may arise. For example, this one-liner can't work either as a doctest: >>> print 'hi', 1/0 hi Traceback (most recent call last): File "", line 1, in ZeroDivisionError: integer division or modulo by zero So there's nothing specific to generators in this, rather it's a doctest limitation. The docs do say, wrt testing exceptions: """ No problem, provided that the traceback is the only output produced by the example: just paste in the traceback. """ In any case, it wasn't intended that doctest support this, and the docs do try to communicate that. I added text spelling out the other half (if there's expected output in addition to the traceback, problem ;-)), in rev 45677 on the trunk and rev 45678 on the 2.4 branch, and am closing this report as a doc bug. Edward Loper tried supporting this, as a new feature, before 2.4 was released, but it so grossly complicated the docs and the implementation that we agreed to drop it. So you could re-open this as a feature request, but it's unlikely to change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337990&group_id=5470 From noreply at sourceforge.net Mon Apr 24 10:31:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 01:31:33 -0700 Subject: [ python-Bugs-1473979 ] test test_capi crashed -- thread.error: can't allocate lock Message-ID: Bugs item #1473979, was opened at 2006-04-21 10:27 Message generated for change (Comment added) made by shashikala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test test_capi crashed -- thread.error: can't allocate lock Initial Comment: Hi , This is shashikala . I am building Python 2.4.3 0n HP- UX 11.23 platform, the building of went smooth buit while testing Python using gmake test test_capi is failing . The Error is "test test_capi crashed -- thread.error: can't allocate lock" . Could you please help in fixing the above error. I am attaching the file which has details of the testing . Thanks and Regards, shashikala ---------------------------------------------------------------------- >Comment By: shashi (shashikala) Date: 2006-04-24 15:31 Message: Logged In: YES user_id=1506183 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-21 10:50 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473979&group_id=5470 From noreply at sourceforge.net Mon Apr 24 11:40:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 02:40:32 -0700 Subject: [ python-Feature Requests-1475397 ] compute/doc %z os-indep., time.asctime_tz / _TZ Message-ID: Feature Requests item #1475397, was opened at 2006-04-24 11:40 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=1475397&group_id=5470 Please note that this 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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: compute/doc %z os-indep., time.asctime_tz / _TZ Initial Comment: Very often I need (for logging purposes, legal international action confirmation display, ...) quickly a stable/constant/technical/international timezone info in addition to %c / .asctime. And find me regularly checking if the computer/server displays %Z nice, writing 10-liner funcs ... found %z by trial (and in footnote) yet time.strftime('%c %z') flickers (on Windows..) think, %z can be computed very easily independent of OS libs? time.altzone /% 3600 ... ==> "+/-HHMM" ? that could be doc'ed. ( the sign of time.timezone / time.altzone is unfortunately revers of RFC standardds , yet its ok doced. there should be a function/update-function for long running apps also ? ) then .asctime_tz() would be very nice to find it in the docs. (and maybe asctime_TZ) -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1475397&group_id=5470 From noreply at sourceforge.net Mon Apr 24 12:39:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 03:39:57 -0700 Subject: [ python-Feature Requests-1436203 ] getpass.getpass() should allow Unicode prompts Message-ID: Feature Requests item #1436203, was opened at 2006-02-21 22:52 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436203&group_id=5470 Please note that this 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 Submitted By: Daniel Herding (wikipedian) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() should allow Unicode prompts Initial Comment: Hi, when using Python 2.4.1 on Linux, I get this: >>> import getpass >>> getpass.getpass(u'Contrase??a: ') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/getpass.py", line 35, in unix_getpass passwd = _raw_input(prompt) File "/usr/lib/python2.4/getpass.py", line 74, in _raw_input prompt = str(prompt) UnicodeEncodeError: 'ascii' codec can't encode character u'\xf1' in position 8: ordinal not in range(128) This one works, but only if the user's console is using UTF-8 encoding: >>> getpass.getpass(u'Contrase??a: '.encode('utf-8')) Contrase??a: I think you should be able to directly give a Unicode string to getpass(), as you can also give a Unicode string to print. Daniel ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-04-24 12:39 Message: Logged In: YES user_id=972995 That error line in getpass should probably simply be commented out? Whats your sys.stdout.encoding ? (Probably not enough for spanish chars as well) The others will probably recommend to create sitecustomize.py I'd say: Its a general trouble with Python that (console) output encoding is in 'strict' mode by default. That crashes more apps, than it helps for discipline ... And its hard even to grasp it and switch it for 'replace': you'd need to replace sys.stdout with a custom formatter etc.. On MS Windows OS the MBCS conversion is kind of 'replace' for good reason. Even in Python on Win: u"abc\u034adef".encode('mbcs') does replacing. tty's,browser,windows,... and maybe most text mode files (and even bin ones (latin1/replace?) ?) should not break. The cases, where encoding should break strictly are naturally cases where the programmer is aware (and puts the conversion into strict mode expicitely) "Python cannot print": Even a harmless >>> print u"abc\u034adef" throws an exception. That is questionable enough: http://groups.google.de/group/comp.lang.python/msg/eac9b025b93e0642 Maybe in future Python: * encoding tuples should be accepted everywhere as alternative to second argument: .encode((enc,error)) * text file's .encoding/.write_encoding=(xy,'replace') or (xy,'backslashreplace') * bin file's .encoding=('latin1','strict') * site(customize).py's defaultencoding should be/accept a tuple ('ascii','replace') -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1436203&group_id=5470 From noreply at sourceforge.net Mon Apr 24 16:19:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 07:19:50 -0700 Subject: [ python-Bugs-1475554 ] Poorly worded description for socket.makefile() Message-ID: Bugs item #1475554, was opened at 2006-04-24 10: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=1475554&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Poorly worded description for socket.makefile() Initial Comment: On the "7.2.1 Socket Objects" page, under makefile(), it says "The socket should be in blocking mode". If I understand it correctly, it MUST be in blocking mode. "Must" implies a mandatory requirement, "should" implies a suggestion of the best way to do something. This comment applies to many places in the Python docs. There should be a comprehensive review of all the docs to clarify "should" vs. "must" usage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 From noreply at sourceforge.net Mon Apr 24 16:20:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 07:20:48 -0700 Subject: [ python-Bugs-1475554 ] Poorly worded description for socket.makefile() Message-ID: Bugs item #1475554, was opened at 2006-04-24 10:19 Message generated for change (Settings changed) made by roysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 Please note that this 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.4 Status: Open Resolution: None >Priority: 3 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Poorly worded description for socket.makefile() Initial Comment: On the "7.2.1 Socket Objects" page, under makefile(), it says "The socket should be in blocking mode". If I understand it correctly, it MUST be in blocking mode. "Must" implies a mandatory requirement, "should" implies a suggestion of the best way to do something. This comment applies to many places in the Python docs. There should be a comprehensive review of all the docs to clarify "should" vs. "must" usage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 From noreply at sourceforge.net Mon Apr 24 19:45:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 10:45:29 -0700 Subject: [ python-Bugs-1475692 ] replacing obj.__dict__ with a subclass of dict Message-ID: Bugs item #1475692, was opened at 2006-04-24 20: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=1475692&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: replacing obj.__dict__ with a subclass of dict Initial Comment: >>> class mydict(dict): ... def __getitem__(self, key): ... return 17 ... >>> class blah(object): ... def __init__(self): ... self.__dict__ = mydict() ... >>> b = blah() >>> print b.x Traceback (most recent call last): File "", line 1, in ? AttributeError: 'blah' object has no attribute 'x' python doesn't call the overriden version of __getitem__. i've done several more tests, and the cause to this problem, afaik, is that the code assumes __dict__ is an instance of dict, so it directly uses PyDict_GetItem (or whatever it's called), thus skipping the overriden method. python should either disable setting __dict__ to anything that is not a real dict (type(x) == dict instead of isinstance(x, dict)), or be willing to call overriden methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475692&group_id=5470 From noreply at sourceforge.net Tue Apr 25 00:31:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 15:31:59 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-08 18:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-24 15:31 Message: Logged In: YES user_id=24670 OK, it looks like the only way to get this bug fixed is to reimplement patch to use stack instead of heap, so that here we go. Attached please find new version of the patch which allocates address buffer on stack. -Maxim ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 16:05 Message: Logged In: YES user_id=24670 > The big win is in simplification of the code. What do you call "big simplification"? Several malloc/free calls and appropriate NULL checks? Aside from stack usage issues the big loss here is portability - we either need to use some fixed length buffer with the size sufficient to hold any type of address (ugly!) or use sockaddr_storage, which may not exist on all platforms supported by the python. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 15:51 Message: Logged In: YES user_id=21627 The big win is in simplification of the code. Also, we are not talking about 10k here. On Linux, sock_addr_t is 128 bytes. Take a look at set_error: it allocates 100 bytes for an error buffer. Or sock_repr: 512 bytes for a buffer. Or socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex: 16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes Or, looking at other modules: symtable.c:check_unoptimized: 300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv: 2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on. Don't worry about stack consumption. Or, if you do, analyse the Python source code, and fix the big offenders first. Premature optimization is the root of all evil. ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 15:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-17 14:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the stack (which certainly wouldn't be the case here). Allocation on the stack is cheap, and over-allocation doesn't hurt. Please change the patch to use automatic variables. It will become simpler and more maintainable that way (in addition, it should also become minimally faster). ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 13:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 22:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-10 17:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-09 14:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Apr 25 07:47:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 22:47:13 -0700 Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword Message-ID: Bugs item #1474677, was opened at 2006-04-22 09:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 Please note that this 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 Submitted By: George Yoshida (quiver) >Assigned to: Jeremy Hylton (jhylton) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-24 22:47 Message: Logged In: YES user_id=33168 Jeremy, could you look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 From noreply at sourceforge.net Tue Apr 25 07:48:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Apr 2006 22:48:09 -0700 Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword Message-ID: Bugs item #1474677, was opened at 2006-04-22 09:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 Please note that this 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 Submitted By: George Yoshida (quiver) Assigned to: Jeremy Hylton (jhylton) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-24 22:48 Message: Logged In: YES user_id=33168 Confirmed 2.5 behaviour and regression from 2.[34]. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-24 22:47 Message: Logged In: YES user_id=33168 Jeremy, could you look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 From noreply at sourceforge.net Tue Apr 25 15:02:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 06:02:38 -0700 Subject: [ python-Bugs-1476111 ] SystemError in socket sendto Message-ID: Bugs item #1476111, was opened at 2006-04-25 15: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=1476111&group_id=5470 Please note that this 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 Submitted By: CyDefect (cydefect) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError in socket sendto Initial Comment: A socket's sendto method can be tricked into a SystemError exception. This happens with: Linux special 2.4.29 #19 Thu Jan 27 20:51:25 CET 2005 i686 unknown and Python 2.4.2 (#2, Dec 27 2005, 11:06:14) but: Linux vesuv6 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003 i686 unknown unknown GNU/Linux Python 2.3.3 (#1, Jun 29 2004, 14:43:40) [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. shows the same behaviour. These 4 lines demonstrate the failure: import socket s = socket.socket( socket.PF_PACKET, socket.SOCK_RAW, socket.htons( 0x0003 ) ) s.sendto( "abc", 0, range( 6 ) ) yields: Traceback (most recent call last): File "serr.py", line 7, in ? s.sendto( "abc", 0, range( 6 ) ) SystemError: new style getargs format but argument is not a tuple HTH, Gerald ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476111&group_id=5470 From noreply at sourceforge.net Tue Apr 25 15:59:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 06:59:26 -0700 Subject: [ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix Message-ID: Bugs item #1433877, was opened at 2006-02-17 23:29 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Quentin Barnes (qbarnes) >Assigned to: Thomas Wouters (twouters) Summary: string parameter to ioctl not null terminated, includes fix Initial Comment: I ran across this problem in Python 2.3.3 and see it is still there in 2.4.2. When running the test_pty.py test case, I would get intermittant failures depending on how the test was invoked or the compiler flags used on Solaris. Trussing the interpreter while running the test revealed: ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL There was garbage on the end of the string when it would fail. I tracked the problem back to fcntl_ioctl() in fcntlmodule.c. The string was not being NULL terminated, but relied on having zeroed gargage on the stack to work. I checked the source for 2.4.2 and noticed the same problem. Patch to fix the problem is attached. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-25 15:59 Message: Logged In: YES user_id=34209 Checked this in before 2.5 alpha2, after more contemplation. Undid the circumventing of the test_pty problems, too. Decided to explicitly set the terminating NUL after all, instead of relying on the given buffer to have one (even though it really should), and terminated the array in the writable-buffer case, too (it may not matter, but it certainly doesn't hurt, since we didn't end up copying any data there in any case.) Thanks for figuring it out, Quentin. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-04-12 16:52 Message: Logged In: YES user_id=34209 Hrm. After giving this some thought, perhaps we should do memcpy(buf, str, len+1) instead of memcpy(buf, str, len) buf[len] = '\0' (And do this in the writable-buffer case as well, when we use memcpy.) Other than that, I think this is the right fix. Assigning to mwh for second (third? fourth?) opinion. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:22 Message: Logged In: YES user_id=34209 Huh, I never even saw this patch, in spite of the high priority and it being assigned to me. We didn't discuss it at PyCon (at least, I wasn't party to the discussion) but I guess this patch doesn't really hurt, and does fix actual problems. I'm wary of fudging fcntl/ioctl too much; I'd _much_ rather try and come up with a decent interface for Py3k, with mutable bytestrings and all that, maybe some nice automatic argument-type-conversion or higher-level interface for common features (like advisory locks) -- and only keep 2.x's fcntl working as well as it does. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 21:52 Message: Logged In: YES user_id=6380 mwh: Sorry about the docstring gripe -- I read the fcntl() docstring which is right above the ioctl() implementation and never realized that this particular C module places the doc strings *after* the functions. (I think that's bad style but there it is.) I think the priority was set to 9 by Neal to get Thomas' attention. gbarnes: We'll decide this one at PyCon. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-20 19:00 Message: Logged In: YES user_id=288734 I didn't write new code that causes this problem by calling ioctl with a string that needed to be null terminated. It was already in Python code itself. See Lib/pty.py for the code. I reworked the patch as discussed below and retested it. All built-in tests passed. I've attached it. I hae no idea of Python coding conventions or style. Hopefully I didn't violate them too badly. (This was weird. SF rejected the text above when I submitted it, but it took the patch file. The patch file shows up as "nobody". Resubmitting this text.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-20 11:54 Message: Logged In: YES user_id=6656 Seeing as some of this is my code... Guido, the ioctl docstring *does* mention mutate_arg. I agree that the documentation should have been updated for 2.4 and 2.5... and the situation is a mess, yes, but one that I couldn't see a better way around when the feature was added (it was much discussed in the bug report at the time). It certainly never occurred to me that you might need/want to pass a NULL terminated string to ioctl. I don't think this is a priority 9 report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 06:04 Message: Logged In: YES user_id=6380 Sorry for the confusion. I was in part responding to an off-line discussion I had with Neal Norwitz, to which you weren't a party. You can ignore my comments about safety and crashing. The difference in marshalling Python data to C data for ioctl(), compared to the many other places where (indeed) this problem has been solved before, is that almost everywhere else, we *know* what the data is supposed to mean. C has many more data types than Python, and the choice of how to convert a string, or an int, to C data depends on what is expected by the receiver of the C data. Unfortunately for ioctl we don't know the required C data type because it's defined by the kernel module that handles the particular ioctl opcode. Some of these (like the one you apparently ran into when porting the pty code to Solaris) require a null-terminated string; others (like the classic tty ioctls) require a C structure, which in Python can be created by using the struct module. Both return Python strings. I tend to agree with your conclusion that we should extend the buffer to 1025 bytes and not bother null-terminating non-string data. Would you like to attempt another patch? ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-20 01:31 Message: Logged In: YES user_id=288734 I've practically never used python. I just found this bug in the interpreter while porting the tool to the current Solaris compiler release, so please keep that in mind about my lack of python knowledge. I also have no idea who's who as well in the python world so forgive me if I've stepped on anyone's toes. I don't follow the remark about "making ioctl 'safe'". I never said anything about making it "safe". It's about a bug. I also never said anything about the interpreter crashing. The interpreter never crashed. The pty test just simply failed since the module name passed to the OS's ioctl was corrupted. Are you sure you responded to the right bug report with these remarks? Anyways... This problem should be reduced to a classic data marshaling problem between python data space and C data space which should have already been addressed in many contexts many times before in the interpreter. How are python strings converted for use by C in similar situations? This problem I encountered is either a bug in the code that passed the string to the ioctl service by not putting an explicit '\0' on the end of the "ptem" string, or it is a bug in the fcntlmodule.c which should have done it for it. Which is it? If a python code isn't expected to put a literal null at the end of their string when passing to a C service, then ioctl needs to be fixed similar to the way in my patch. As for null-terminating other raw data, I don't see the point other than a defensive programming practice. The problem I ran across is limited to just a data marshaling problem. The patch only touched the case when the type of data passed to ioctl is known to be a string. As for the buffer vs. documentation, the buffer could be changed to 1025 for the string case, or the documentation could be updated to clarify that, unlike raw data, strings are limited to 1023 to leave room for the requisite null that conversion to a C string requires. I don't think anyone would care either way as long as it is qualified. Since python strings serve dual roles of being both raw data and being just textual containers, one can't assume that a string passed to ioctl is always meant to be just a textual string. Going the 1025 route is probably a 'better' approach due to python string's duality. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-19 21:03 Message: Logged In: YES user_id=6380 One problem with ioctl() is that the required length of the buffer is unknown unless you parse the operation code argument in a very platform- (and probably even kernel- and driver-) dependent way. Whether null-terminating it makes sense or not depends on the particular operation code. I don't think the patch makes ioctl "safe", and I'm not sure it even ought to be applied. A quick code review reveals a few more issues: - the docstring doesn't explain the optional "mutate_flag" argument (which BTW is a mess -- read the online docs -- why are we changing the default to true?) - the online docs ought to be updated for 2.4 and again for 2.5 -- they still speak of 2.4 in the future tense! Also, it's a bit strong to say this function is "identical" to fcntl() -- "similar" sounds more like it. - In the first branch of the function, this line: if (mutate_arg && (len < sizeof buf)) { ought to test (len <= sizeof buf) to match the test earlier; but probably better is to use if (mutate_arg && arg == buf) { - If it's important to null-terminate the data in the buffer when a string is passed in, shouldn't we null-terminate it also when a writable buffer-interface object is passed in? If not in the latter case, why if a string is passed? One could argue that a string with an explicit \0 (visible to Python code) at the end ought to be passed in if the semantics of the op code requires a null-terminated argument (which most ioctl op codes don't -- the typical argument is a C struct). - The proposed patch reduces the maximum buffer size to 1023, which violates the docs. (Yes the docs explicitly mention 1024.) - The best we can do seems to be: increase the buffer size to 1025; null-pad it in all cases; change the code for mutable buffers to test for sizeof buf - 1. This still leaves the case where the buffer isn't used because a mutable buffer is passed that's longer than 1024. Which suggests that we can't completely fix this -- it will always be possible to crash Python using this function by passing an op code that encodes a buffer length > 1024 while passing a shorter argument, so the internal buffer is used. I guess we could do the null-padding as long as we document it and document that when a mutable buffer is passed we don't guarantee it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-18 08:14 Message: Logged In: YES user_id=33168 Thomas, could this have caused the flakiness that you just fixed with test_pty? This patch seems correct to me and I think it should be applied. (If you want I can do that, but I wanted you to see this first.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 From noreply at sourceforge.net Tue Apr 25 16:32:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 07:32:53 -0700 Subject: [ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py Message-ID: Feature Requests item #1476166, was opened at 2006-04-25 18:32 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=1476166&group_id=5470 Please note that this 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 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Add SeaMonkey to webbrowser.py Initial Comment: Add SeaMonkey to webbrowser.py as yet another Mozilla family browser. Just prepend "seamonkey" to the list ("mozilla-firefox", "firefox", "mozilla-firebird", "firebird", "mozilla", "netscape") in the register_X_browsers(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470 From noreply at sourceforge.net Tue Apr 25 17:08:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 08:08:51 -0700 Subject: [ python-Bugs-1476111 ] SystemError in socket sendto Message-ID: Bugs item #1476111, was opened at 2006-04-25 15:02 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476111&group_id=5470 Please note that this 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 Submitted By: CyDefect (cydefect) >Assigned to: Thomas Wouters (twouters) Summary: SystemError in socket sendto Initial Comment: A socket's sendto method can be tricked into a SystemError exception. This happens with: Linux special 2.4.29 #19 Thu Jan 27 20:51:25 CET 2005 i686 unknown and Python 2.4.2 (#2, Dec 27 2005, 11:06:14) but: Linux vesuv6 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003 i686 unknown unknown GNU/Linux Python 2.3.3 (#1, Jun 29 2004, 14:43:40) [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. shows the same behaviour. These 4 lines demonstrate the failure: import socket s = socket.socket( socket.PF_PACKET, socket.SOCK_RAW, socket.htons( 0x0003 ) ) s.sendto( "abc", 0, range( 6 ) ) yields: Traceback (most recent call last): File "serr.py", line 7, in ? s.sendto( "abc", 0, range( 6 ) ) SystemError: new style getargs format but argument is not a tuple HTH, Gerald ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-04-25 17:08 Message: Logged In: YES user_id=34209 Well, 'tricked' is a bit of a big word; it just means you passed the wrong type of address; AF_PACKET expects a tuple (of string+int or int+int+string), and not a list. It didn't have any ill effects (other than confusing the programmer.) I fixed the errormessage for AF_PACKET (and AF_INET6, which was also missing) in trunk revision 45714 (so it'll be in 2.5 alpha 2.) Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476111&group_id=5470 From noreply at sourceforge.net Tue Apr 25 18:05:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 09:05:50 -0700 Subject: [ python-Bugs-1476216 ] Documentation date stuck on "5th April 2006" Message-ID: Bugs item #1476216, was opened at 2006-04-25 09:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470 Please note that this 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 Submitted By: Mat Martineau (martineau) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation date stuck on "5th April 2006" Initial Comment: My builds of the python documentation from the SVN trunk have been stuck on "5th April 2006" for several weeks now. I've traced this to r43589, which hard-coded the date in boilerplate.tex - this seems unusual, because boilerplate.tex was not modified in this way for any previous releases. Seems like "\date{5th April 2006}" should be changed back to "\date{\today}". For some reason, the documentation at http://docs.python.org/dev/ shows the correct date. Mat ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470 From noreply at sourceforge.net Tue Apr 25 19:08:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 10:08:47 -0700 Subject: [ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9 Message-ID: Bugs item #1437614, was opened at 2006-02-23 13:48 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Li Quid (liquid333) Assigned to: Nobody/Anonymous (nobody) Summary: can't send files via ftp on my MacOS X 10.3.9 Initial Comment: When trying to do a simple ftp upload using Python 2.3's ftplib, it fails and I get a socket error. The exact error is (61, 'Connection refused'). This happens to me in all my scripts that use the ftplib on MacOS 10.3.9, but not in scripts on my Windows box. I've attached the small, simple source code. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 15:28 Message: Logged In: YES user_id=580910 I use ftplib on OSX and don't see problems (both python 2.3 and 2.4 on OSX 10.3 and 10.4). I agree with tjreedy that this is most likely a problem with the environment of the user. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 21:26 Message: Logged In: YES user_id=593130 This could be a problem in your specific machine and its setup, the specific OS version, the specific target (maybe nyx doesn't like MACs), or the specific Python version. I would start by installing 2.4.2 and see if there have maybe been helpful changes to its socket code. And try to find another Mac box. And then ask on python- list/comp.lang.python for other experiences with Max, OSX, sockets, and maybe ftp. Since the error message comes from the OS blaming nyx, I think more likely than not that this is not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 From noreply at sourceforge.net Tue Apr 25 22:11:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 13:11:40 -0700 Subject: [ python-Bugs-1476356 ] StringIO should implement __str__() Message-ID: Bugs item #1476356, was opened at 2006-04-25 16:11 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=1476356&group_id=5470 Please note that this 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 Submitted By: Dom Lachowicz (cinamod) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO should implement __str__() Initial Comment: I was a bit surprised when I discovered that StringIO didn't have a __str__() method, equivalent to getvalue(). Calling str(stringio_object) gives the following: >>> import StringIO >>> s = StringIO.StringIO("hello world") >>> print "%s" % (str(s)) I had some (perhaps dodgy code) code that did: if isinstance(data, types.FileType): return data.read() else: return str(data) Since StringIO doesn't subclass any file type and doesn't implement a __str__() method, I was getting seemingly bogus results. This was trivially worked around by adding another "isinstance(data, StringIO.StringIO)" case, but it was surprising nonetheless. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 From noreply at sourceforge.net Tue Apr 25 22:59:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 13:59:24 -0700 Subject: [ python-Bugs-1471427 ] tarfile.py chokes on long names Message-ID: Bugs item #1471427, was opened at 2006-04-16 22:34 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470 Please note that this 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 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py chokes on long names Initial Comment: The following bug is reproducible on Py 2.4.3 and 2.5. It was tested on Windows. You need a tarfile with a long file name that triggers the GNU LONGNAME extension. Extracting such a file gives me an IO error because it tries to create a file with a slash at the end. This is because # Some old tar programs represent a directory as a regular # file with a trailing slash. if tarinfo.isreg() and tarinfo.name.endswith("/ "): tarinfo.type = DIRTYPE sets the type incorrectly after it was called from the callback proc which has no possiblity to set the name of the intermediary tarinfo class because it is instantiated in the next-method. So this yields a directory which should be a file which is obviously wrong. Might be related to commit 41340 "Patch #1338314, Bug #1336623". (At least the code changed there is causing this bug). ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-04-25 22:59 Message: Logged In: YES user_id=642936 Fixing this issue is not quite as simple as I hoped it to be. It would be possible to implement a quick fix that solves the problem, but that would be too ugly for a stdlib module. Instead, I have been busy writing a preliminary fix for my development version of tarfile.py which is available at http://www.gustaebel.de/lars/tarfile/. It would be nice of you, if you'd download the 0.8.0 version there and give it a try. Thank you. ---------------------------------------------------------------------- Comment By: Alexander Schremmer (alexanderweb) Date: 2006-04-16 22:34 Message: Logged In: YES user_id=254738 Hmm, I just want to clarify that tarfile doesn't give the IO error (it passes silently) but my code that expects a file instead of a directory ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&group_id=5470 From noreply at sourceforge.net Wed Apr 26 00:58:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 15:58:23 -0700 Subject: [ python-Bugs-1476356 ] StringIO should implement __str__() Message-ID: Bugs item #1476356, was opened at 2006-04-25 15:11 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 Please note that this 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 Submitted By: Dom Lachowicz (cinamod) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO should implement __str__() Initial Comment: I was a bit surprised when I discovered that StringIO didn't have a __str__() method, equivalent to getvalue(). Calling str(stringio_object) gives the following: >>> import StringIO >>> s = StringIO.StringIO("hello world") >>> print "%s" % (str(s)) I had some (perhaps dodgy code) code that did: if isinstance(data, types.FileType): return data.read() else: return str(data) Since StringIO doesn't subclass any file type and doesn't implement a __str__() method, I was getting seemingly bogus results. This was trivially worked around by adding another "isinstance(data, StringIO.StringIO)" case, but it was surprising nonetheless. Thanks. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-25 17:58 Message: Logged In: YES user_id=80475 This isn't a bug. The module is correctly emulating the API for file objects. I recommend replacing your isintance() test with a try/except: try: .... return data.read() except AttributeError: .... return str(data) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 From noreply at sourceforge.net Wed Apr 26 01:00:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 16:00:48 -0700 Subject: [ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity Message-ID: Bugs item #1472695, was opened at 2006-04-18 20:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 Please note that this 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 Submitted By: Peter Maxwell (pm67nz) >Assigned to: Tim Peters (tim_one) Summary: 32/64bit pickled Random incompatiblity Initial Comment: The unsigned long integers which make up the state of a Random instance are converted to Python integers via a cast to long in _randommodule.c's random_getstate function, so on a 32bit platform Random.getstate() returns a mix of postitive and negative integers, while on a 64bit platform the negative numbers are replaced by larger positive numbers, their 32bit-2s-complement equivalents. As a result, unpicking a Random instance from a 64bit machine on a 32bit platform produces the error "OverflowError: long int too large to convert to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the resulting object is in a slightly confused state: >>> r32 = cPickle.load(open('r32_3.pickle')) >>> for i in range(3): ... print r64.random(), r32.random() ... 0.237964627092 4292886520.32 0.544229225296 0.544229225296 0.369955166548 4292886520.19 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-25 18:00 Message: Logged In: YES user_id=80475 Tim, do you think we should require that the world not change for 32-bit pickles? ---------------------------------------------------------------------- Comment By: Peter Maxwell (pm67nz) Date: 2006-04-21 01:03 Message: Logged In: YES user_id=320286 OK, here is a candidate patch, though I don't know if it is the best way to do it or meets the style guidelines etc. It makes Random pickles interchangable between 32bit and 64bit machines by encoding their states as Python long integers. An old pre-patch 32bit pickle loaded on a 64bit machine still fails (OverflowError: can't convert negative value to unsigned long) but I hope that combination is rare enough to ignore. Also on a 32bit machine new Random pickles can't be unpickled by a pre-patch python, but again there are limits to sane backward compatability. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 02:02 Message: Logged In: YES user_id=33168 Peter, thanks for the report. Do you think you could work up a patch to correct this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 From noreply at sourceforge.net Wed Apr 26 02:26:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 17:26:44 -0700 Subject: [ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity Message-ID: Bugs item #1472695, was opened at 2006-04-18 21:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 Please note that this 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 Submitted By: Peter Maxwell (pm67nz) >Assigned to: Raymond Hettinger (rhettinger) Summary: 32/64bit pickled Random incompatiblity Initial Comment: The unsigned long integers which make up the state of a Random instance are converted to Python integers via a cast to long in _randommodule.c's random_getstate function, so on a 32bit platform Random.getstate() returns a mix of postitive and negative integers, while on a 64bit platform the negative numbers are replaced by larger positive numbers, their 32bit-2s-complement equivalents. As a result, unpicking a Random instance from a 64bit machine on a 32bit platform produces the error "OverflowError: long int too large to convert to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the resulting object is in a slightly confused state: >>> r32 = cPickle.load(open('r32_3.pickle')) >>> for i in range(3): ... print r64.random(), r32.random() ... 0.237964627092 4292886520.32 0.544229225296 0.544229225296 0.369955166548 4292886520.19 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-25 20:26 Message: Logged In: YES user_id=31435 > do you think we should require that the world not > change for 32-bit pickles? I don't understand the question. If a pre-2.5 pickle here can be read in 2.5, where both producer & consumer are the same 32-vs-64 bit choice; and a 2.5+ pickle here is portable between 32- and 64- boxes, I'd say "good enough". While desirable, it's not really critical that a 2.5 pickle here be readable by an older Python. While that's critical for pickle in general, and critical too for everyone-uses-'em types (ints, strings, lists, ...), when fixing a bug in a specific rarely-used type's pickling strategy some slop is OK. IOW, it's just not worth heroic efforts to hide all pain. The docs should mention incompatibilities, though. Does that answer the question? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-25 19:00 Message: Logged In: YES user_id=80475 Tim, do you think we should require that the world not change for 32-bit pickles? ---------------------------------------------------------------------- Comment By: Peter Maxwell (pm67nz) Date: 2006-04-21 02:03 Message: Logged In: YES user_id=320286 OK, here is a candidate patch, though I don't know if it is the best way to do it or meets the style guidelines etc. It makes Random pickles interchangable between 32bit and 64bit machines by encoding their states as Python long integers. An old pre-patch 32bit pickle loaded on a 64bit machine still fails (OverflowError: can't convert negative value to unsigned long) but I hope that combination is rare enough to ignore. Also on a 32bit machine new Random pickles can't be unpickled by a pre-patch python, but again there are limits to sane backward compatability. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 03:02 Message: Logged In: YES user_id=33168 Peter, thanks for the report. Do you think you could work up a patch to correct this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470 From noreply at sourceforge.net Wed Apr 26 04:53:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 19:53:28 -0700 Subject: [ python-Bugs-1476356 ] StringIO should implement __str__() Message-ID: Bugs item #1476356, was opened at 2006-04-25 16:11 Message generated for change (Comment added) made by cinamod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 Please note that this 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 Submitted By: Dom Lachowicz (cinamod) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO should implement __str__() Initial Comment: I was a bit surprised when I discovered that StringIO didn't have a __str__() method, equivalent to getvalue(). Calling str(stringio_object) gives the following: >>> import StringIO >>> s = StringIO.StringIO("hello world") >>> print "%s" % (str(s)) I had some (perhaps dodgy code) code that did: if isinstance(data, types.FileType): return data.read() else: return str(data) Since StringIO doesn't subclass any file type and doesn't implement a __str__() method, I was getting seemingly bogus results. This was trivially worked around by adding another "isinstance(data, StringIO.StringIO)" case, but it was surprising nonetheless. Thanks. ---------------------------------------------------------------------- >Comment By: Dom Lachowicz (cinamod) Date: 2006-04-25 22:53 Message: Logged In: YES user_id=69417 The StringIO API diverges from the file API already. It adds API (getvalue()) doesn't implement the encoding, mode, name, newlines, or softspace attributes, and implements isatty() in violation of the section 2.3.9 docs. In some contexts, it may look like a file, but it isn't a file. And I don't see how implementing __str__() changes that. It's equivalent to saying that Java's StringBuffer class shouldn't override toString()... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-25 18:58 Message: Logged In: YES user_id=80475 This isn't a bug. The module is correctly emulating the API for file objects. I recommend replacing your isintance() test with a try/except: try: .... return data.read() except AttributeError: .... return str(data) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 From noreply at sourceforge.net Wed Apr 26 04:54:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 19:54:31 -0700 Subject: [ python-Bugs-1476356 ] StringIO should implement __str__() Message-ID: Bugs item #1476356, was opened at 2006-04-25 16:11 Message generated for change (Comment added) made by cinamod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 Please note that this 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 Submitted By: Dom Lachowicz (cinamod) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO should implement __str__() Initial Comment: I was a bit surprised when I discovered that StringIO didn't have a __str__() method, equivalent to getvalue(). Calling str(stringio_object) gives the following: >>> import StringIO >>> s = StringIO.StringIO("hello world") >>> print "%s" % (str(s)) I had some (perhaps dodgy code) code that did: if isinstance(data, types.FileType): return data.read() else: return str(data) Since StringIO doesn't subclass any file type and doesn't implement a __str__() method, I was getting seemingly bogus results. This was trivially worked around by adding another "isinstance(data, StringIO.StringIO)" case, but it was surprising nonetheless. Thanks. ---------------------------------------------------------------------- >Comment By: Dom Lachowicz (cinamod) Date: 2006-04-25 22:54 Message: Logged In: YES user_id=69417 The StringIO API diverges from the file API already. It adds API (getvalue()) doesn't implement the encoding, mode, name, newlines, or softspace attributes, and implements isatty() in violation of the section 2.3.9 docs. In some contexts, it may look like a file, but it isn't a file. And I don't see how implementing __str__() changes that. It's equivalent to saying that Java's StringBuffer class shouldn't override toString()... ---------------------------------------------------------------------- Comment By: Dom Lachowicz (cinamod) Date: 2006-04-25 22:53 Message: Logged In: YES user_id=69417 The StringIO API diverges from the file API already. It adds API (getvalue()) doesn't implement the encoding, mode, name, newlines, or softspace attributes, and implements isatty() in violation of the section 2.3.9 docs. In some contexts, it may look like a file, but it isn't a file. And I don't see how implementing __str__() changes that. It's equivalent to saying that Java's StringBuffer class shouldn't override toString()... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-25 18:58 Message: Logged In: YES user_id=80475 This isn't a bug. The module is correctly emulating the API for file objects. I recommend replacing your isintance() test with a try/except: try: .... return data.read() except AttributeError: .... return str(data) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 From noreply at sourceforge.net Wed Apr 26 06:15:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Apr 2006 21:15:22 -0700 Subject: [ python-Bugs-1475080 ] example code in what's new/sqlite3 docs Message-ID: Bugs item #1475080, was opened at 2006-04-23 09:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470 Please note that this 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 Submitted By: James Pryor (jpryor68) >Assigned to: A.M. Kuchling (akuchling) Summary: example code in what's new/sqlite3 docs Initial Comment: The documentation at contains the following example code: # Never do this -- insecure! symbol = 'IBM' c.execute("... where symbol = '%s'" % symbol) # Do this instead t = (symbol,) c.execute('select * from stocks where symbol=?', ('IBM',)) The second block should instead read: # Do this instead t = ('IBM',) c.execute('select * from stocks where symbol=?', t) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470 From noreply at sourceforge.net Wed Apr 26 13:57:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 04:57:35 -0700 Subject: [ python-Bugs-1476845 ] Finish PEP 343 terminology cleanup Message-ID: Bugs item #1476845, was opened at 2006-04-26 21: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=1476845&group_id=5470 Please note that this 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 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nick Coghlan (ncoghlan) Summary: Finish PEP 343 terminology cleanup Initial Comment: test_with.py was missed in the PEP 343 terminology cleanup for Python alpha 2 PEP 343 itself still needs to be updated, too. Creating this tracker item to record items needed to finish the terminology cleanup post-alpha 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470 From noreply at sourceforge.net Wed Apr 26 14:19:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 05:19:03 -0700 Subject: [ python-Bugs-1476216 ] Documentation date stuck on "5th April 2006" Message-ID: Bugs item #1476216, was opened at 2006-04-25 12:05 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470 Please note that this 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 Submitted By: Mat Martineau (martineau) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Documentation date stuck on "5th April 2006" Initial Comment: My builds of the python documentation from the SVN trunk have been stuck on "5th April 2006" for several weeks now. I've traced this to r43589, which hard-coded the date in boilerplate.tex - this seems unusual, because boilerplate.tex was not modified in this way for any previous releases. Seems like "\date{5th April 2006}" should be changed back to "\date{\today}". For some reason, the documentation at http://docs.python.org/dev/ shows the correct date. Mat ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-26 08:19 Message: Logged In: YES user_id=11375 This change was made for the 2.5alpha1 release. Undoing the change probably just slipped the release manager's mind. The freeze for alpha2 is very soon, so this will probably get fixed after alpha2 is out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470 From noreply at sourceforge.net Wed Apr 26 14:25:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 05:25:19 -0700 Subject: [ python-Bugs-1475080 ] example code in what's new/sqlite3 docs Message-ID: Bugs item #1475080, was opened at 2006-04-23 12:51 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470 Please note that this 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 Submitted By: James Pryor (jpryor68) Assigned to: A.M. Kuchling (akuchling) Summary: example code in what's new/sqlite3 docs Initial Comment: The documentation at contains the following example code: # Never do this -- insecure! symbol = 'IBM' c.execute("... where symbol = '%s'" % symbol) # Do this instead t = (symbol,) c.execute('select * from stocks where symbol=?', ('IBM',)) The second block should instead read: # Do this instead t = ('IBM',) c.execute('select * from stocks where symbol=?', t) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-26 08:25 Message: Logged In: YES user_id=11375 Fixed in SVN; thanks for pointing this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&group_id=5470 From noreply at sourceforge.net Wed Apr 26 14:42:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 05:42:59 -0700 Subject: [ python-Bugs-1473048 ] SimpleXMLRPCServer responds to any path Message-ID: Bugs item #1473048, was opened at 2006-04-19 11:45 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470 Please note that this 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 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer responds to any path Initial Comment: SimpleXMLRPCServer and DocXMLRPCServer don't look at the path of the HTTP request at all; you can POST or GET from / or /RPC2 or /blahblahblah with the same results. One minor problem with this liberality is that a security scanner that looks for vulnerable scripts such as /cgi-bin/phf will report the server as vulnerable. Nessus, for example, reports dozens of security holes on a SimpleXMLRPCServer for this reason. Fix: add a check that only allows '/' or '/RPC2' (maybe just /RPC2?). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-26 08:42 Message: Logged In: YES user_id=11375 The attached patch adds a .rpc_paths attribute that's a tuple of legal paths, and a .is_rpc_path_valid() method that returns True if a path is OK. A .report_404() method generates a 404 error message, and SimpleXMLRPCServer and DocXMLRPCServer are modified to check for legal paths. (Perhaps it should be ._report_404?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470 From noreply at sourceforge.net Wed Apr 26 17:09:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 08:09:33 -0700 Subject: [ python-Bugs-1476356 ] StringIO should implement __str__() Message-ID: Bugs item #1476356, was opened at 2006-04-25 16:11 Message generated for change (Comment added) made by cinamod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 Please note that this 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 Submitted By: Dom Lachowicz (cinamod) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO should implement __str__() Initial Comment: I was a bit surprised when I discovered that StringIO didn't have a __str__() method, equivalent to getvalue(). Calling str(stringio_object) gives the following: >>> import StringIO >>> s = StringIO.StringIO("hello world") >>> print "%s" % (str(s)) I had some (perhaps dodgy code) code that did: if isinstance(data, types.FileType): return data.read() else: return str(data) Since StringIO doesn't subclass any file type and doesn't implement a __str__() method, I was getting seemingly bogus results. This was trivially worked around by adding another "isinstance(data, StringIO.StringIO)" case, but it was surprising nonetheless. Thanks. ---------------------------------------------------------------------- >Comment By: Dom Lachowicz (cinamod) Date: 2006-04-26 11:09 Message: Logged In: YES user_id=69417 Since section 2.3.9 of the docs doesn't mention anything about an overriden meaning of FILE.__str__(), its meaning in that API is undefined. "Correctly emulating" undefined API is impossible. ---------------------------------------------------------------------- Comment By: Dom Lachowicz (cinamod) Date: 2006-04-25 22:54 Message: Logged In: YES user_id=69417 The StringIO API diverges from the file API already. It adds API (getvalue()) doesn't implement the encoding, mode, name, newlines, or softspace attributes, and implements isatty() in violation of the section 2.3.9 docs. In some contexts, it may look like a file, but it isn't a file. And I don't see how implementing __str__() changes that. It's equivalent to saying that Java's StringBuffer class shouldn't override toString()... ---------------------------------------------------------------------- Comment By: Dom Lachowicz (cinamod) Date: 2006-04-25 22:53 Message: Logged In: YES user_id=69417 The StringIO API diverges from the file API already. It adds API (getvalue()) doesn't implement the encoding, mode, name, newlines, or softspace attributes, and implements isatty() in violation of the section 2.3.9 docs. In some contexts, it may look like a file, but it isn't a file. And I don't see how implementing __str__() changes that. It's equivalent to saying that Java's StringBuffer class shouldn't override toString()... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-25 18:58 Message: Logged In: YES user_id=80475 This isn't a bug. The module is correctly emulating the API for file objects. I recommend replacing your isintance() test with a try/except: try: .... return data.read() except AttributeError: .... return str(data) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&group_id=5470 From noreply at sourceforge.net Wed Apr 26 19:28:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 10:28:14 -0700 Subject: [ python-Bugs-1477102 ] Missing import line in example Message-ID: Bugs item #1477102, was opened at 2006-04-26 10: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=1477102&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Eckel (bruceeckel) Assigned to: Nobody/Anonymous (nobody) Summary: Missing import line in example Initial Comment: 11.22.9 Example of Client Usage Should include the following import line: from xmlrpclib import ServerProxy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477102&group_id=5470 From noreply at sourceforge.net Wed Apr 26 20:20:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 11:20:20 -0700 Subject: [ python-Bugs-1477140 ] Incorrect code in example Message-ID: Bugs item #1477140, was opened at 2006-04-26 11: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=1477140&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Bruce Eckel (bruceeckel) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect code in example Initial Comment: In 11.22.9 Example of Client Usage The line: except Error, v: should probably be: except Exception, v: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477140&group_id=5470 From noreply at sourceforge.net Thu Apr 27 01:16:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 16:16:23 -0700 Subject: [ python-Bugs-1391608 ] missing module names in email package Message-ID: Bugs item #1391608, was opened at 2005-12-27 21:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Genellina (gagenellina) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: missing module names in email package Initial Comment: Documentation for modules inside the email package lacks reference to module name in title (and body too). By example, there is no clue in 12.2.1 that the Message class being described is contained in the email.Message module. Or 12.2.2 doesnt menction that FeedParser, HeaderParser and Parser are all classes contained in module email.Parser. And so on. Looking at other similar standard packages (like curses) seems that the module name should appear first in the title. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-26 19:16 Message: Logged In: YES user_id=3066 Assigned to the email tsar. This is complicated by the dual-naming approach for Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470 From noreply at sourceforge.net Thu Apr 27 01:19:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 16:19:36 -0700 Subject: [ python-Bugs-1386675 ] _winreg specifies EnvironmentError instead of WindowsError Message-ID: Bugs item #1386675, was opened at 2005-12-20 20:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 Please note that this 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 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Mark Hammond (mhammond) Summary: _winreg specifies EnvironmentError instead of WindowsError Initial Comment: The _winreg documentation says that EnvironmentError will be raised (throughout the docs, for various reasons), when, in every case, WindowsError is actually raised. A simple replace of WindowsError for EnvironmentError would fix this. (Let me know if you really need a patch). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-26 19:19 Message: Logged In: YES user_id=3066 Assigning to Mark Hammond since he should be able to tell us what the docs *should* say, and why. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-27 12:26 Message: Logged In: YES user_id=1188172 You're right. I reverted the checkin, assigning to Fred. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-27 03:08 Message: Logged In: YES user_id=38376 The original checkin used EnvironmentError in both the documentation and the docstrings, so this is not a result of some accidental editing. Since a good documentation policy for a portable language is to document intended usage, not implementation artifacts, you should at least check with the original authors before you make the documentation depend on the current CPython implementation. (and no, using EnvironmentError is an entirely different thing than using Exception. Can we keep the hyperbolic arguments on comp.lang.python, please?) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-26 19:03 Message: Logged In: YES user_id=1188172 Corrected in rev. 41829/41830. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2005-12-25 21:36 Message: Logged In: YES user_id=552329 I don't see what purpose there is in having the documentation say that EnvironmentError is raised, when a subclass is. _winreg is still marked as a temporary module to be replaced, so it's hard to believe it's some sort of future-proofing. One could say that Exception is raised, since EnvironmentError is a subclass of Exception, but explicit is better than implicit, right? (import _winreg fails on non-Windows platforms, so I don't see how it could be for cross-platform reasons, either). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-25 06:44 Message: Logged In: YES user_id=38376 however, note that >>> issubclass(WindowsError, EnvironmentError) True on windows, and >>> issubclass(WindowsError, EnvironmentError) Traceback (most recent call last): File "", line 1, in NameError: name 'WindowsError' is not defined on non-windows platforms, so it might be done this way on purpose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1386675&group_id=5470 From noreply at sourceforge.net Thu Apr 27 01:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 16:30:48 -0700 Subject: [ python-Bugs-1124692 ] Math mode not well handled in \documentclass{howto} Message-ID: Bugs item #1124692, was opened at 2005-02-17 08:08 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Math mode not well handled in \documentclass{howto} Initial Comment: LaTeX loses its Math Magic (tm) when using \documentclass{howto}: underscore operator in math enviroment doesn't produce subscripts. This documents shows some oddities: \documentclass{howto} \begin{document} Water is $H_2O$, and subscript is missing from... \[ V_{0,r} \] Superscripts are instead fine, as $e^{\pi i} + 1 = 0$ shows. Also this is completely different from what obtained by \textbackslash documentclass\{article\}. \[ \sum_{k=0}^\infty \int_0^k f(x) dx \] \end{document} The bug is removed by commenting out lines 541--549 in python.sty, but i don't know how to *fix* them... (not a TeXpert) Using Python 2.3.5, Windows 2000, LaTeX2e (e-TeX 3.141592-2.2, MikTex 2.4 implementation) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-26 19:30 Message: Logged In: YES user_id=3066 Boy, has this lingered! Everything seems to be fine with the current version using your example docuement, so I'm closing this as out of date. Please respond if you're still having trouble with the latest version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470 From noreply at sourceforge.net Thu Apr 27 02:04:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 17:04:20 -0700 Subject: [ python-Bugs-839709 ] Windows non-MS compiler doc updates Message-ID: Bugs item #839709, was opened at 2003-11-10 21:47 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Windows non-MS compiler doc updates Initial Comment: Documents affected: http://www.python.org/doc/2.3.2/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3.1/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.2.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1/inst/tweak-flags.html sec. 3.1.2 1. Filenames in the examples are way out of date. It is also not clear to the reader that python23.dll is located in %SystemRoot%\System32. I suggest that you change the pexports command line example to pexports \Windows\System32\python23.dll > python23.def In the Python 2.2 docs, use python22.dll and python22.def. In the Python 2.1 docs, use python21.dll and python21.def. 2. It's not clear to the reader where dlltool is. dlltool can also output directly to the right directory. I suggest that you change the dlltool command line example to \cygwin\bin\dlltool --dllname python23.dll --def python23.def --output-lib \Python23\Libs\libpython23.a In the Python 2.2 docs, use python22.dll, python22.def, and libpython22.a. In the Python 2.1 docs, use python21.dll, python21.def and libpython21.a. 3. Another filename out of date. I suggest that you change "The resulting library has to be placed in the same directory as python20.lib." to "The resulting library has to be placed in the same directory as python23.lib." In the Python 2.2 docs, use python22.lib. In the Python 2.1 docs, use python21.lib. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-26 20:04 Message: Logged In: YES user_id=3066 --sigh-- I guess I've not had a lot of time for the past few years. :-( Luckily, most of this has already been handled for newer releases. I've made updates based on 1 and 2 for the Python 2.5 documentation (revision 45738). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 From noreply at sourceforge.net Thu Apr 27 02:08:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 17:08:09 -0700 Subject: [ python-Bugs-624827 ] Creation of struct_seq types Message-ID: Bugs item #624827, was opened at 2002-10-17 14:51 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Nobody/Anonymous (nobody) Summary: Creation of struct_seq types Initial Comment: It would be really nice to be able to create structure sequence types from within Python. MvL suggested: ------------------- ... I think all you need to do is to expose PyStructSequence_InitType. I would recommend an interface like struct_seq(name, doc, n_in_sequence, (fields)) where fields is a list of (name,doc) tuples. You will need to temporarily allocate a PyStructSequence_Field array of len(fields)+1 elements, and put the PyStructSequence_Desc on the stack. You will also need to dynamically allocate a PyTypeObject which you return. I would put this into the new module. ------------------- Assigned to me since I actually wanted to create these things. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-26 20:08 Message: Logged In: YES user_id=3066 I'm not going to have any time to look at this; hopefully somebody else can, since it's a pretty reasonable idea I think. It may not be as valuable as it once was, however (subclassing tuple and using properties has become more attractive using an @property decoration). ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2004-06-25 21:13 Message: Logged In: YES user_id=393416 Uploaded patch 980098 which implements this functionality as a separate module. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-22 16:26 Message: Logged In: YES user_id=3066 As part of this, struct_seq types should be made subclassable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470 From noreply at sourceforge.net Thu Apr 27 02:14:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Apr 2006 17:14:07 -0700 Subject: [ python-Bugs-1411674 ] "print statement" in libref index broken Message-ID: Bugs item #1411674, was opened at 2006-01-21 14:50 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470 Please note that this 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 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: "print statement" in libref index broken Initial Comment: The "print statement" entry in the libref index refers the user to http://www.python.org/dev/doc/devel/lib/types.html#l2h-92 The source (libstdtypes.tex): \ulink{\keyword{print} statement}{../ref/print.html} suggests that the link should be to the reference manual. Something's fishy. This was reported on comp.lang.python by peter at monicol.co.uk. His report was against the current doc, but the problem still exists in the development version. Just passing it along... ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-04-26 20:14 Message: Logged In: YES user_id=3066 I think it's reasonable. It's about the fact that print uses the str() function, so it's clearly about the print statement. This information is good to have linked from the index, I think. No need to change anything. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-21 14:59 Message: Logged In: YES user_id=1188172 The output is okay. The \ulink you state does not add the index entry, it's the \stindex one line above it. But it's questionable whether this mention of print merits an index entry. Fred? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470 From noreply at sourceforge.net Thu Apr 27 09:07:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 00:07:46 -0700 Subject: [ python-Bugs-1477450 ] test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Message-ID: Bugs item #1477450, was opened at 2006-04-27 14:07 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=1477450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Initial Comment: Hi , Iam building Python-2.4.3 on HP-UX 11.2i , while testing its npt able import the _bsddb.sl module and hence that is skipped . In previous versions the test is passing. what can be done to pass the test?. Thanks, shashi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 From noreply at sourceforge.net Thu Apr 27 14:26:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 05:26:11 -0700 Subject: [ python-Bugs-1476216 ] Documentation date stuck on "5th April 2006" Message-ID: Bugs item #1476216, was opened at 2006-04-25 12:05 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Mat Martineau (martineau) Assigned to: Anthony Baxter (anthonybaxter) Summary: Documentation date stuck on "5th April 2006" Initial Comment: My builds of the python documentation from the SVN trunk have been stuck on "5th April 2006" for several weeks now. I've traced this to r43589, which hard-coded the date in boilerplate.tex - this seems unusual, because boilerplate.tex was not modified in this way for any previous releases. Seems like "\date{5th April 2006}" should be changed back to "\date{\today}". For some reason, the documentation at http://docs.python.org/dev/ shows the correct date. Mat ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-27 08:26 Message: Logged In: YES user_id=11375 Now that 2.5alpha2 is out, I've reverted boilerplate.tex to use the current date. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-04-26 08:19 Message: Logged In: YES user_id=11375 This change was made for the 2.5alpha1 release. Undoing the change probably just slipped the release manager's mind. The freeze for alpha2 is very soon, so this will probably get fixed after alpha2 is out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476216&group_id=5470 From noreply at sourceforge.net Thu Apr 27 14:34:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 05:34:05 -0700 Subject: [ python-Bugs-1477102 ] Missing import line in example Message-ID: Bugs item #1477102, was opened at 2006-04-26 13:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477102&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bruce Eckel (bruceeckel) >Assigned to: A.M. Kuchling (akuchling) Summary: Missing import line in example Initial Comment: 11.22.9 Example of Client Usage Should include the following import line: from xmlrpclib import ServerProxy ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-27 08:34 Message: Logged In: YES user_id=11375 fixed in SVN; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477102&group_id=5470 From noreply at sourceforge.net Thu Apr 27 14:50:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 05:50:37 -0700 Subject: [ python-Bugs-1477140 ] Incorrect code in example Message-ID: Bugs item #1477140, was opened at 2006-04-26 14:20 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477140&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bruce Eckel (bruceeckel) >Assigned to: A.M. Kuchling (akuchling) Summary: Incorrect code in example Initial Comment: In 11.22.9 Example of Client Usage The line: except Error, v: should probably be: except Exception, v: ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-04-27 08:50 Message: Logged In: YES user_id=11375 I think the code was intending to use xmlrpclib.Error, which is the base class for both Fault and ProtocolError, but there were two problems: the missing import didn't make that clear, and the Error class wasn't mentioned in the documentation. I've fixed the import and added a description of the Error exception. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477140&group_id=5470 From noreply at sourceforge.net Thu Apr 27 14:59:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 05:59:32 -0700 Subject: [ python-Feature Requests-1474609 ] feature requests for logging lib Message-ID: Feature Requests item #1474609, was opened at 2006-04-22 12:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474609&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: blaize rhodes (blaize) Assigned to: Nobody/Anonymous (nobody) Summary: feature requests for logging lib Initial Comment: The logger module interface is a bit broken, I reckon. My problems specifically are: i) It's hard to get access to the LogRecord classes for customization. ii) the semantics of the debug, log, info, etc calls is a bit strange/confusing... Here are my proposed fixes: a) Add a method Logger.setLogRecordClass( myLogRecordSubClass ) which sets the class that is instantiated in the makeRecord() fn/method (yes there are two of them). This would make customizing the LogRecord easier... Otherwise (I believe) in order to subclass the LogRecord you also have to overload the Logger and possibly the root makeRecord() function as well? This bloke's writen up his approach to this (it's doable but not as nice as it should be). http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html Another problem is that LogRecords are instantiated in Logger._log so it's difficult to customize __init__ behaviour for the LogRecord (and I argue that this is a useful thing).. b) A second problem is that the semantics of the log, info, debug, etc fns is a bit broken. Currently the defn looks like this: def debug(self, msg, *args, **kwargs): this suggests to me that a call like this is OK... logger.debug("here we go %(foo)s", foo = 'bar') but it's not. This is discussed further here... http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881 Instead kwargs are used for customizing the behaviour of the debug method (e.g. exc_info, and extra). This seems i) a bit incongrous with its definition and therefore confusing, and ii) a bit of a hack (it's not completely insane though when you think about what's happening under the hood). Instead I propose using a couple of calls along the lines of printf/fprintf. In my world we'd have a simple printf-style function... def debug(self, msg, *args): and a more complex, more easily customizable fprintf-style one def x_debug(self, log_record, msg, *args): In these calls *args is a valid argument for the string formatting operator %, either a tuple of the right length or a dictionary. Any customization of the behaviour of the system can be done (using keyword args if you wish) in the log_record initializer (an example will follow). (Having said that perhaps we can check whether the first arg to the new simple debug() is a logrecord and if it is call the (hidden) extended version - that's more pythonic I imagine) c) This is not so much a feature request but a motivating mode of operation that I'd like to be able to use... Currently you can set up log filters. What you can filter is largely based on what information appears in the log record. It'd be nice to filter messages based on metadata that you add at log time (i.e. in the logger.debug(...) method). Currently it's quite painfull to set this up. This is because we can't customize the initialization of the log_record. The call structure in ii) above allows us to setup nice filtering mechanisms eg.. class GUIFilter: "A filter that only lets messges with gui tags through.""" def filter(self, log_record): return hasattr(log_record, 'gui') # set up a log, and a handler... log = logging.getLogger(..) file_handler = FileHandler(..) log.addHandler(file_handler) gui_msg_bar_handler = StreamHandler(..) log.addHandler(gui_msg_bar_handler) gui_msg_bar_handler.addFilter(GUIFilter()) # msg only goes to the file_handler log.debug("here we go %s", "here's an arg") # msg goes to the file_handler and to the gui_handler. log.x_debug(LogRecord(gui=True), "what you just tried to do didn't work %s", "fool") Change a) could be made with no backward compatability problems (I can see), change b) could be made without probs if you didn't overload the existing logging methods with the new ones, and then deprecate the existing ones (though what you'd call the new fns I don't know). That said I quite like the logger lib and I use it. It's a lot better than anything I would have thought up. cheers blaize ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-27 12:59 Message: Logged In: YES user_id=849994 Duplicate of #1474577. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474609&group_id=5470 From noreply at sourceforge.net Thu Apr 27 15:01:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 06:01:53 -0700 Subject: [ python-Bugs-1472566 ] import module with .dll extension Message-ID: Bugs item #1472566, was opened at 2006-04-18 20:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Submitted By: svenn (sven_nystrom) Assigned to: Martin v. L??wis (loewis) Summary: import module with .dll extension Initial Comment: In previous versions, extension modules with the file extension '.dll' could be imported using a single 'import' statement. In 2.5a1 this seems to have changed - here's an example: >>> import minx # Implemented in a .dll - fails Traceback (most recent call last): File "", line 1, in ImportError: No module named minx >>> import imp # Workaround >>> import os >>> minx = imp.load_dynamic('minx', os.getcwd() + '\\minx.dll') I would really like this to remain the same; if that's not possible, it would be helpful if the change itself and a suggested approach were to be included in the documentation. /Sven ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-27 13:01 Message: Logged In: YES user_id=849994 Closing as "Won't fix", then. ---------------------------------------------------------------------- Comment By: svenn (sven_nystrom) Date: 2006-04-22 16:25 Message: Logged In: YES user_id=1504966 Hi loewis, I', sure the .pyd extension will work fine - my original comment was due to the fact I didn't realise it would work as today if the file extension was changed; I was (wrongly) assuming I would have to use the approach indicated in my example, which seemed a little less intuitive than the simple "import". ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-22 14:26 Message: Logged In: YES user_id=21627 Tim mentions the rationale for the change; the Misc/NEWS entry is now in r45574. svenn, why do you need it to work that way? Could you change your code/application/whatever so that it works with .pyd files instead? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-19 17:16 Message: Logged In: YES user_id=31435 Note that rev 43622 added a comment to dynload_win.c explaining why it was done: """ /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll and the sqlite3 package. If this needs to be reverted for 2.5, some other solution for the naming conflict must be found. """ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 07:13 Message: Logged In: YES user_id=33168 I believe this was an intentional change in rev 43622. I don't see any doc associated with the change however. I also thought it was mentioned on python-dev. Martin, shouldn't this be documented at least in Misc/NEWS? I couldn't find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470 From noreply at sourceforge.net Thu Apr 27 15:06:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 06:06:22 -0700 Subject: [ python-Bugs-944394 ] No examples or usage docs for urllib2 Message-ID: Bugs item #944394, was opened at 2004-04-29 11:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-27 13:06 Message: Logged In: YES user_id=849994 Chris, I concur with jjlee that suggesting examples is the best way to get something done. Perhaps, if you're using urllib2, you could flesh out some examples from your code? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-17 14:26 Message: Logged In: YES user_id=261020 Do you have any specific suggestions for what is unhelpful and/or missing? Otherwise, nothing is likely to change. Note that a little was added at the bottom of this page in 2.4, explaining how OpenerDirector uses the handlers to open URLs: http://docs.python.org/lib/opener-director-objects.html Looking at the top-level page, I guess an introduction / overview would help? Did you have other stuff in mind too? ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-04-17 14:19 Message: Logged In: YES user_id=24723 I still feel there could be more. I guess the best course, for me, would be to leave this open but at a really low priority. However, I probably wouldn't scream too much if the issue was closed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:49 Message: Logged In: YES user_id=261020 They are here: http://docs.python.org/lib/urllib2-examples.html ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2006-04-15 18:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 17:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-06-01 08:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-05-31 21:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 From noreply at sourceforge.net Thu Apr 27 15:07:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 06:07:52 -0700 Subject: [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific addressing Message-ID: Bugs item #764437, was opened at 2003-07-02 07:13 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: AF_UNIX sockets do not handle Linux-specific addressing Initial Comment: As described in unix(7) manpage, Linux allows for special "kernel namespace" AF_UNIX sockets defined. With such sockets, the first byte of the path is \x00, and the rest is the address. These sockets do not show up in the filesystem. socketmodule.c:makesockaddr (as called by recvfrom) uses code like PyString_FromString(a->sun_path) to retrieve the address. This is incorrect -- on Linux, if the first byte of a->sun_path is null, the function should use PyString_FromStringAndSize to retrieve the full 108- byte buffer. I am not entirely sure that this is the only thing that needs to be fixed, but bind() and sendto() work with these sort of socket paths just fine. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-13 20:03 Message: Logged In: YES user_id=4771 I'm about to check in a slightly different patch (also at 1062014) which tries to preserve the length of the abstract namespace addresses (the kernel saves this length even though it is not zero-terminated, so that the names '\x00abc' and '\x00abc\x00' and '\x00abc\x00\x00' are all different in theory). The patch no longer exposes UNIX_PATH_MAX because I'm not sure it's useful any more. If anyone who is relying on this Linux extension more than myself has comments, now would be a good time :-) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-08 11:03 Message: Logged In: YES user_id=129426 Patch is at 1062014 The comments below state that UNIX_PATH_MAX is defined in sys/un.h, but it isn't. The patch gets it in another (hopefully portable) way (and also exposes it as a new constant in the socket module) ---------------------------------------------------------------------- Comment By: Aaron Brady (insomnike) Date: 2004-07-07 14:39 Message: Logged In: YES user_id=1057404 It should use UNIX_PATH_MAX, but it should also check that the length of the buffer supplied is correct, my bad. ---------------------------------------------------------------------- Comment By: Pavel Pergamenshchik (ppergame) Date: 2004-07-07 14:37 Message: Logged In: YES user_id=595126 """The socket?s address in this namespace is given by the rest of the bytes in sun_path. Note that names in the abstract namespace are not zero‐terminated.""" The length would be UNIX_PATH_MAX in this case. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-07 14:04 Message: Logged In: YES user_id=11375 Should it use UNIX_PATH_MAX as the length of the string, or 1+ strlen(a->sun_path+1)? (The leading null byte, plus the following null-terminated string?) ---------------------------------------------------------------------- Comment By: Aaron Brady (insomnike) Date: 2004-06-05 19:16 Message: Logged In: YES user_id=1057404 Also checks for "linux" to be defined, on Mondragon's recommendation. ### --- socketmodule.c 3 Jun 2004 09:24:42 -0000 1.291 +++ socketmodule.c 5 Jun 2004 18:17:51 -0000 @@ -942,6 +942,11 @@ case AF_UNIX: { struct sockaddr_un *a = (struct sockaddr_un *) addr; +#if defined(UNIX_PATH_MAX) && defined(linux) + if (*a->sun_path == 0) { + return PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX); + } +#endif /* UNIX_PATH_MAX && linux */ return PyString_FromString(a->sun_path); } #endif /* AF_UNIX */ ### ---------------------------------------------------------------------- Comment By: Aaron Brady (insomnike) Date: 2004-06-05 19:06 Message: Logged In: YES user_id=1057404 The below patch adds the functionality if UNIX_PATH_MAX is defined (in Linux it's in sys/un.h). ### --- socketmodule.c 3 Jun 2004 09:24:42 -0000 1.291 +++ socketmodule.c 5 Jun 2004 18:08:47 -0000 @@ -942,6 +942,11 @@ case AF_UNIX: { struct sockaddr_un *a = (struct sockaddr_un *) addr; +#if defined(UNIX_PATH_MAX) + if (*a->sun_path == 0) { + return PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX); + } +#endif /* UNIX_PATH_MAX */ return PyString_FromString(a->sun_path); } #endif /* AF_UNIX */ ### ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-25 08:13 Message: Logged In: YES user_id=29957 Eek. What a totally mental design decision on the part of the Linux kernel developers. Is there a magic C preprocessor symbol we can use to detect that this insanity is available? (FWIW, Perl also has problems with this: http://www.alexhudson.com/code/abstract-sockets-and-perl ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 From noreply at sourceforge.net Thu Apr 27 16:46:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 07:46:03 -0700 Subject: [ python-Bugs-1229380 ] No struct.pack exception for some out of range integers Message-ID: Bugs item #1229380, was opened at 2005-06-28 16:30 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470 Please note that this 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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Neal Norwitz (nnorwitz) Summary: No struct.pack exception for some out of range integers Initial Comment: struct.pack("B", -1) generates an OverflowError exception since the B format corresponds to the "unsigned char" type which can have values between 0 and 255. But struct.pack("I", -1) and struct.pack("L", -1) do not generate these errors, even if struct.pack("I", -1L) and struct.pack("L", -1L) do (notice the final L). ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-04-27 07:46 Message: Logged In: YES user_id=971153 Also it appears that there is some kind of interference between range checking and byte-order chars: import struct; struct.pack("H", 70000) #Exception import struct; struct.pack(">H", 70000) # no exception ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 12:52 Message: Logged In: YES user_id=849994 Attaching patch, raises struct.error. Neal, please look over it. Note that I find struct's error handling confusing: it's not clear from the docs in which cases OverflowError is raised, and in which struct.error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470 From noreply at sourceforge.net Thu Apr 27 18:43:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 09:43:32 -0700 Subject: [ python-Bugs-1250389 ] The -m option to python does not search zip files Message-ID: Bugs item #1250389, was opened at 2005-08-02 17:55 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-04-27 17:43 Message: Logged In: YES user_id=113328 I can confirm that this has been fixed in 2.5a2 ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-11-10 10:26 Message: Logged In: YES user_id=113328 I assume you meant PEP 338. I'm completely in favour of that. I didn't give feedback simply because I had nothing constructive to add beyond "+1"... (And I agree that PEP 338 is more important than this bug - but I'd like to see both sorted :-)) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-10 09:05 Message: Logged In: YES user_id=1038590 I agree this is a significant limitation on -m, although I think it actually pales in comparison to the fact you can't use modules inside packages. So please take a look at PEP 328 and provide feedback on it. I've had absolutely *zero* feedback on it since I wrote it, and have had to assume that no-one else was bothered by the current limitations. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-08-11 19:33 Message: Logged In: YES user_id=113328 I have looked into this, and it appears that _PyImportHooks_Init is getting called properly, and the zipimport mechanism is getting initialised (python -v -m a where a.py is in a zip file on sys.path shows this). The problem seems to be that main.c calls, in Py_Main, _PyImport_FindModule, with the "loader" argument set to NULL, which disables handling of PEP 302 style import hooks. This makes sense, to the extent that the current code needs a real FILE* to call PyRun_AnyFileExFlags, it should be possible (by calling PyRun_SimpleStringFlags instead, maybe?) to execute a module loaded from a hook. Unfortunately, I can't take this any further at present, as I don't have the means to build Python in order to test a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 From noreply at sourceforge.net Thu Apr 27 22:34:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 13:34:39 -0700 Subject: [ python-Feature Requests-1477968 ] Drop py.ico and pyc.ico Message-ID: Feature Requests item #1477968, was opened at 2006-04-27 22:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1477968&group_id=5470 Please note that this 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 Submitted By: Martin v. L??wis (loewis) Assigned to: Martin v. L??wis (loewis) Summary: Drop py.ico and pyc.ico Initial Comment: These files should be dropped from the Windows distribution, as they duplication python_icon.exe, and confuse tab completion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1477968&group_id=5470 From noreply at sourceforge.net Fri Apr 28 05:11:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 20:11:44 -0700 Subject: [ python-Bugs-1477450 ] test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Message-ID: Bugs item #1477450, was opened at 2006-04-27 00:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Initial Comment: Hi , Iam building Python-2.4.3 on HP-UX 11.2i , while testing its npt able import the _bsddb.sl module and hence that is skipped . In previous versions the test is passing. what can be done to pass the test?. Thanks, shashi ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 20:11 Message: Logged In: YES user_id=33168 The test can't pass without being able to import _bsddb.sl. Why can't this file be imported? When you build python it should print out what version of bsddb is found. It will look something like this: running build running build_ext db.h: found (4, 1) in /usr/include db lib: using (4, 1) db-4.1 What version of bsddb was found on your box? Are there compile errors when building bsddb? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 From noreply at sourceforge.net Fri Apr 28 06:35:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 21:35:00 -0700 Subject: [ python-Bugs-1477450 ] test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Message-ID: Bugs item #1477450, was opened at 2006-04-27 14:07 Message generated for change (Comment added) made by shashikala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Initial Comment: Hi , Iam building Python-2.4.3 on HP-UX 11.2i , while testing its npt able import the _bsddb.sl module and hence that is skipped . In previous versions the test is passing. what can be done to pass the test?. Thanks, shashi ---------------------------------------------------------------------- >Comment By: shashi (shashikala) Date: 2006-04-28 11:35 Message: Logged In: YES user_id=1506183 Hi, I am having db-4.4.20 installed, It looks like Python doesn't support 4.4.20 version , hence i built 4.2.52 , now I am getting segmentation fault (memory fault) and its dumping core . I want to know the versions of the dependent libraries Python-2.4.3 supports and also while testing the Python test_subprocess.py is also dumping core. I am sending out the outputs of test_bsddb and test_subprocess. Thanks, shashi ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-28 10:11 Message: Logged In: YES user_id=33168 The test can't pass without being able to import _bsddb.sl. Why can't this file be imported? When you build python it should print out what version of bsddb is found. It will look something like this: running build running build_ext db.h: found (4, 1) in /usr/include db lib: using (4, 1) db-4.1 What version of bsddb was found on your box? Are there compile errors when building bsddb? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 From noreply at sourceforge.net Fri Apr 28 06:45:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Apr 2006 21:45:51 -0700 Subject: [ python-Bugs-1477450 ] test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Message-ID: Bugs item #1477450, was opened at 2006-04-27 00:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb skipped -- Failed to load /home/shashi/Python-2.4 Initial Comment: Hi , Iam building Python-2.4.3 on HP-UX 11.2i , while testing its npt able import the _bsddb.sl module and hence that is skipped . In previous versions the test is passing. what can be done to pass the test?. Thanks, shashi ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 21:45 Message: Logged In: YES user_id=33168 Support for db-4.4 was added late. I believe the only thing you need to do to enable it is modify setup.py, line 496 (proabably that line) should be: max_db_ver = (4, 4) >From what I've seen, you are much better off with newer versions of bdb. As for the seg faults, I wonder if your ulimits are too low. What is the output of: ulimit -a Also, can you attach the output of ./python Lib/test/regrtest.py -v -u bsddb test_subprocess and do the same for test_bsddb3 (or test_bsddb whichever is crashing). ---------------------------------------------------------------------- Comment By: shashi (shashikala) Date: 2006-04-27 21:35 Message: Logged In: YES user_id=1506183 Hi, I am having db-4.4.20 installed, It looks like Python doesn't support 4.4.20 version , hence i built 4.2.52 , now I am getting segmentation fault (memory fault) and its dumping core . I want to know the versions of the dependent libraries Python-2.4.3 supports and also while testing the Python test_subprocess.py is also dumping core. I am sending out the outputs of test_bsddb and test_subprocess. Thanks, shashi ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-27 20:11 Message: Logged In: YES user_id=33168 The test can't pass without being able to import _bsddb.sl. Why can't this file be imported? When you build python it should print out what version of bsddb is found. It will look something like this: running build running build_ext db.h: found (4, 1) in /usr/include db lib: using (4, 1) db-4.1 What version of bsddb was found on your box? Are there compile errors when building bsddb? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1477450&group_id=5470 From noreply at sourceforge.net Fri Apr 28 10:59:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 01:59:30 -0700 Subject: [ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion Message-ID: Bugs item #1478253, was opened at 2006-04-28 08:59 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=1478253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 00003930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 From noreply at sourceforge.net Fri Apr 28 11:55:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 02:55:15 -0700 Subject: [ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes Message-ID: Bugs item #1462152, was opened at 2006-03-31 15:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 Please note that this 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 Submitted By: Matt Fleming (splitscreen) >Assigned to: Tim Peters (tim_one) Summary: Python does not check for POSIX compliant open() modes Initial Comment: Python does not check for POSIX-compliant modes when passing them to open() and fopen(). According to the POSIX standard all modes should start with either an 'a', 'r' or 'w'. This patch implements this check in the check_the_mode() function of fileobject.c and a test has been modified in the test_file.py test. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 09:55 Message: Logged In: YES user_id=849994 Tim: Did you review file-modes.diff which is really the latest patch? (There's no test in it either, but I'll add one when I check it in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-24 01:19 Message: Logged In: YES user_id=31435 This is still ;-) fine with me. There doesn't seem to be a test in fileobject2.diff. WRT the docs, "must either be" should say "must be one of" instead ("either" is proper for two choices, but there are three). It should state that this requirement is new in Python 2.5; in LaTeX, something like \versionchanged[Restriction on first letter of mode string introduced]{2.5} ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-12 10:14 Message: Logged In: YES user_id=1126061 Yeah, your patch looks much better. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-06 08:15 Message: Logged In: YES user_id=849994 splitscreen: your patch was incomplete and could have overwritten memory. tim_one: Attaching new patch implementing what I proposed in my comment below. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 21:59 Message: Logged In: YES user_id=1126061 Ok, uploading latest patch, not quite sure I've hit the mark here. Please review. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 20:43 Message: Logged In: YES user_id=849994 Yes, I want to remove 'U' from the mode since it's at this point already recognized by Python, and it's not meaningful to the underlying C library. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 19:32 Message: Logged In: YES user_id=1126061 Ignore my question, it's for "universal newlines", right? Have I understood your proposal correctly in that you want to remove the 'U' from the mode? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-01 14:14 Message: Logged In: YES user_id=1126061 That seems sensible. What does a mode containing 'U' mean anyway? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-01 07:08 Message: Logged In: YES user_id=849994 Instead of this patch, I'd rather like check_the_mode to * remove any 'U' from the mode string * if 'U' was found: * error out if the new string begins with 'w' or 'a' * add a 'r' and 'b' if it isn't already given * if not: * error out if the string doesn't begin with 'w', 'r', 'a' What do you think of it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-31 18:03 Message: Logged In: YES user_id=31435 There's a small danger of backward-incompatibility here, since platforms are free to support any goofy mode characters they like, and Python just passes on whatever the user typed. I understand that some MS compilers in debug mode raise internal exceptions, but that's an MS bug and the workaround is dead easy ("don't do that"). All that said, I'm in favor of this patch ;-). However, if it goes in two things are needed: 1. The error message should be more informative, like PyErr_Format(PyExc_ValueError, "mode argument must " "begin with 'w', 'r', or 'a', not '%.200s'", mode); 2. The Python docs should change to match (i.e., the manual should document this new restriction on mode strings). WRT the test case, it's more natural to write, e.g., TESTFN in s than s.find(TESTFN) != -1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470 From noreply at sourceforge.net Fri Apr 28 13:22:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 04:22:39 -0700 Subject: [ python-Bugs-1478326 ] Invalid value returned by util.get_platform() on HP Message-ID: Bugs item #1478326, was opened at 2006-04-28 13: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=1478326&group_id=5470 Please note that this 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 Submitted By: S?bastien Sabl? (sable) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid value returned by util.get_platform() on HP Initial Comment: Hi, I am working on a HP platform which is reported like this by os.uname: >>> print os.uname() >>> ('HP-UX', 'newton', 'B.11.23', 'U', '9000/800') as a result, distuils.util.get_platform() reports the following value: hp-ux-B.11.23-9000/800 Since this value is used by distutils "mainly to distinguish platform-specific build directories", this value is invalid as it contains a '/'; as a result the directory structure in the build directory is messed up and the installation fails. The following patch corrected the problem: --- util.py.old 2006-04-28 11:13:19.000000000 +0200 +++ util.py 2006-04-28 13:17:31.000000000 +0200 @@ -44,6 +44,7 @@ # (to accommodate BSD/OS), and translate spaces (for "Power Macintosh") osname = string.lower(osname) osname = string.replace(osname, '/', '') + machine = string.replace(machine, '/', '-') machine = string.replace(machine, ' ', '_') if osname[:5] == "linux": regards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478326&group_id=5470 From noreply at sourceforge.net Fri Apr 28 15:38:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 06:38:00 -0700 Subject: [ python-Feature Requests-1465406 ] Allowing the definition of constants Message-ID: Feature Requests item #1465406, was opened at 2006-04-05 23:30 Message generated for change (Comment added) made by ciw42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? ---------------------------------------------------------------------- >Comment By: Chris Wilson (ciw42) Date: 2006-04-28 13:38 Message: Logged In: YES user_id=1018283 I see your point, and it's a good example of why using namespaces is so important, but in practice, with my proposal in place, the code you propose simply wouldn't compile. Assuming the compiler simply substituted the literal "3.1415" for "pi" as I've proposed, you'd end up with "3.1415 = 4", and a syntax error for trying to assign to a literal value. You'd not get as far as running the code, so in practice there'd be no issues with it running incorrectly. Being able to declare constants is important as it allows the compiler to make the sort of optimistations I mentioned previously. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 13:55 Message: Logged In: YES user_id=21627 The problem is that declaring the value assignment const doesn't help. Consider this: from math import pi def area(r): return r*r*pi pi = 4 print area(10) So even though math.pi might be declared as a constant, hard-coding its value into the function area would break this program - the value of the variable pi might change not change inside math, but it might change where it is imported. ---------------------------------------------------------------------- Comment By: Chris Wilson (ciw42) Date: 2006-04-06 21:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-05 23:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 From noreply at sourceforge.net Fri Apr 28 15:45:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 06:45:59 -0700 Subject: [ python-Bugs-1478400 ] test_capi crashed -- thread.error: can't allocate lock Message-ID: Bugs item #1478400, was opened at 2006-04-28 20: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=1478400&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_capi crashed -- thread.error: can't allocate lock Initial Comment: I have build Python 2.4.3 on HP-UX IPF platform and run the gmake test, and seeing the following error: test_capi crashed -- thread.error: can't allocate lock When I see the release notes of the Python 2.4.3, there is a mention of this fix in some platforms. Is this fixed in HP-UX IPF? Please let me know how to reslove this on HP-UX IPF platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478400&group_id=5470 From noreply at sourceforge.net Fri Apr 28 16:37:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 07:37:44 -0700 Subject: [ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error Message-ID: Bugs item #1478429, was opened at 2006-04-28 14: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=1478429&group_id=5470 Please note that this 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 Submitted By: Erwin Bonsma (eriban) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..999999 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.99999976 microsecond must be in 0..999999 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 From noreply at sourceforge.net Fri Apr 28 17:02:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 08:02:53 -0700 Subject: [ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion Message-ID: Bugs item #1478253, was opened at 2006-04-28 10:59 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 00003930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-28 17:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 From noreply at sourceforge.net Fri Apr 28 18:31:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 09:31:44 -0700 Subject: [ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py Message-ID: Feature Requests item #1476166, was opened at 2006-04-25 14:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470 Please note that this 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 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Add SeaMonkey to webbrowser.py Initial Comment: Add SeaMonkey to webbrowser.py as yet another Mozilla family browser. Just prepend "seamonkey" to the list ("mozilla-firefox", "firefox", "mozilla-firebird", "firebird", "mozilla", "netscape") in the register_X_browsers(). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:31 Message: Logged In: YES user_id=849994 Added in rev. 45780. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470 From noreply at sourceforge.net Fri Apr 28 18:37:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 09:37:41 -0700 Subject: [ python-Bugs-1475009 ] Document os.path.join oddity on Windows Message-ID: Bugs item #1475009, was opened at 2006-04-23 13:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&group_id=5470 Please note that this 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 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Document os.path.join oddity on Windows Initial Comment: Please document that on windows os.path.join("m:\\noo", "\\woo") => '\\woo' >From reading the code I see that this is intetional, however it need to be documented. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:37 Message: Logged In: YES user_id=849994 The documentation was already there. I added a parenthetical note that on Windows, the drive letter is also thrown away. (rev. 45781, 45782) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-23 17:38 Message: Logged In: YES user_id=31435 Noting that there's nothing special about Windows here: >>> import posixpath >>> posixpath.join('/noo', '/woo') '/woo' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&group_id=5470 From noreply at sourceforge.net Fri Apr 28 18:39:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 09:39:40 -0700 Subject: [ python-Bugs-1478400 ] test_capi crashed -- thread.error: can't allocate lock Message-ID: Bugs item #1478400, was opened at 2006-04-28 13:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478400&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_capi crashed -- thread.error: can't allocate lock Initial Comment: I have build Python 2.4.3 on HP-UX IPF platform and run the gmake test, and seeing the following error: test_capi crashed -- thread.error: can't allocate lock When I see the release notes of the Python 2.4.3, there is a mention of this fix in some platforms. Is this fixed in HP-UX IPF? Please let me know how to reslove this on HP-UX IPF platform. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:39 Message: Logged In: YES user_id=849994 Duplicate of #1473979. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478400&group_id=5470 From noreply at sourceforge.net Fri Apr 28 18:46:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 09:46:18 -0700 Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network drive Message-ID: Bugs item #1478529, was opened at 2006-04-28 17:46 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=1478529&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 From noreply at sourceforge.net Fri Apr 28 18:55:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 09:55:18 -0700 Subject: [ python-Bugs-1472949 ] shutil.copytree debug message problem Message-ID: Bugs item #1472949, was opened at 2006-04-19 12:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472949&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Christophe DUMEZ (hydr0g3n) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copytree debug message problem Initial Comment: I noticed a problem in shutil.copytree : try: if symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): copytree(srcname, dstname, symlinks) else: copy2(srcname, dstname) # XXX What about devices, sockets etc.? except (IOError, os.error), why: errors.append((srcname, dstname, why)) 'why' isn't displayed in tuple, maybe this line would be better for debug : "errors.append((srcname, dstname, why.strerror))" then, it will display something (for example: 'permission denied'). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:55 Message: Logged In: YES user_id=849994 >From rev. 45785, the line reads errors.append((srcname, dstname, str(why))) This way, you get the full information out of the IOError/OSError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472949&group_id=5470 From noreply at sourceforge.net Fri Apr 28 18:59:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 09:59:28 -0700 Subject: [ python-Bugs-1478326 ] Invalid value returned by util.get_platform() on HP Message-ID: Bugs item #1478326, was opened at 2006-04-28 11:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478326&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: S?bastien Sabl? (sable) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid value returned by util.get_platform() on HP Initial Comment: Hi, I am working on a HP platform which is reported like this by os.uname: >>> print os.uname() >>> ('HP-UX', 'newton', 'B.11.23', 'U', '9000/800') as a result, distuils.util.get_platform() reports the following value: hp-ux-B.11.23-9000/800 Since this value is used by distutils "mainly to distinguish platform-specific build directories", this value is invalid as it contains a '/'; as a result the directory structure in the build directory is messed up and the installation fails. The following patch corrected the problem: --- util.py.old 2006-04-28 11:13:19.000000000 +0200 +++ util.py 2006-04-28 13:17:31.000000000 +0200 @@ -44,6 +44,7 @@ # (to accommodate BSD/OS), and translate spaces (for "Power Macintosh") osname = string.lower(osname) osname = string.replace(osname, '/', '') + machine = string.replace(machine, '/', '-') machine = string.replace(machine, ' ', '_') if osname[:5] == "linux": regards ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:59 Message: Logged In: YES user_id=849994 Fixed in rev. 45786, 45787. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478326&group_id=5470 From noreply at sourceforge.net Fri Apr 28 19:05:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 10:05:26 -0700 Subject: [ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion Message-ID: Bugs item #1478253, was opened at 2006-04-28 08:59 Message generated for change (Comment added) made by balducci You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 00003930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele ---------------------------------------------------------------------- >Comment By: balducci (balducci) Date: 2006-04-28 17:05 Message: Logged In: YES user_id=1452725 Dear Thomas, thank you for your reply. I've investigated a little bit more the problem. 2.5a1 worked smoothly on test_ctypes: this makes me think that the problem isn't in my box (it's an old redhat-7.1, but I keep all the system up-2-date: kernel,X11,glibc etc.). Also, I've kept python up-2-date since 2.3.4 and never seen this. On the other hand, it is also true that the (verbose mode) output of test_ctypes in 2.5a1, while showing a test_GL line, does not contain any test_glu and/or test_glut lines (which, together with test_gl, give the errors in 2.5a2): so it might also be that these new tests (test_glu and test_glut) make some local (i.e. due to my box) problem evident. However, I'm incline to think that there must be something in 2.5a2 which has changed from 2.5a1: => Lib/ctypes/__init__.py heavily differ from 2.5a1 to 2.5a2 (the error reported in the attached file I sent seems to have been generated in __init__.py) => also, the traceback in the attachment quotes a file Lib/ctypes/test/test_find.py, which I don't find in 2.5a1 => the error is quite reasonable: libglut.so.3 does not define XGetExtensionVersion, which is instead defined in libXi.so I seem to understand that exactly this kind of problem was reported in the following thread: http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534 I've seen just now that you got involved there! Well, as I said, I do not speak python, but from a glance to the thread I seem to understand that the problem could be in the use of RTLD_GLOBAL/RTLD_LOCAL (I don't know what these are for, but I guess that RTLD stands for RunTime Loader?) As I understand it, the problem seems to be as if one tries to compile a C program which calls XGetExtensionVersion with -lglut, but without -lXi. Perhaps the corresponding action should be done with test_ctypes, but I have no idea how this is done with python. I've also to admit that being the only one who has reported this problem on such a widespread platfrom like linux makes me perplexed. In the end, I don't know what to think: the problem is actually there and was not there with 2.5a1 (nor with any previous build since 2.3.4). I regret being unable to go deeper in this problem and I apoligize if this report is not clear enough. If there is any test I can do to make things clearer, please, just tell me. And THANK YOU for your work. Ciao Gabriele ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-28 15:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 From noreply at sourceforge.net Fri Apr 28 19:28:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 10:28:29 -0700 Subject: [ python-Bugs-1436226 ] fix inplace assignment for immutable sequences Message-ID: Bugs item #1436226, was opened at 2006-02-21 23:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) >Assigned to: Nobody/Anonymous (nobody) Summary: fix inplace assignment for immutable sequences Initial Comment: Currently: py> tup = ([], ) py> tup[0] += [1] Traceback (most recent call last): File "", line 1, in ? TypeError: object doesn't support item assignment py> tup ([1],) With this patch, no exception will be raised when the item one wants to assign is already there in the tuple. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-22 22:20 Message: Logged In: YES user_id=849994 You're right with the error handling *shame*. I had written the patch a few months ago and just posted it without looking at it again. Well, I don't think I'm able to come up with a new patch only for a couple of days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-22 02:44 Message: Logged In: YES user_id=6380 I see no error handling from the PySequence_GetItem() call; if this causes an error it should take precedence over the TypeError we're about to raise (IOW we shouldn't raise the TypeError). Also, shouldn't the same fix be made for attribute assignment? Finally -- doing this in PySequence_SetItem is too broad. Code like this passes without error: t = (1, 2) t[0] = t[0] That can't be right! You need to find a code path that's only taken for += and friends. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470 From noreply at sourceforge.net Fri Apr 28 19:32:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 10:32:26 -0700 Subject: [ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error Message-ID: Bugs item #1478429, was opened at 2006-04-28 14:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 Please note that this 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 Submitted By: Erwin Bonsma (eriban) >Assigned to: Martin v. L??wis (loewis) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..999999 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.99999976 microsecond must be in 0..999999 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 From noreply at sourceforge.net Fri Apr 28 19:32:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 10:32:48 -0700 Subject: [ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error Message-ID: Bugs item #1478429, was opened at 2006-04-28 14:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 Please note that this 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 Submitted By: Erwin Bonsma (eriban) Assigned to: Martin v. L??wis (loewis) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..999999 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.99999976 microsecond must be in 0..999999 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Really attaching a patch now. ;) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 From noreply at sourceforge.net Fri Apr 28 20:11:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 11:11:31 -0700 Subject: [ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error Message-ID: Bugs item #1478429, was opened at 2006-04-28 10:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Erwin Bonsma (eriban) >Assigned to: Georg Brandl (gbrandl) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..999999 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.99999976 microsecond must be in 0..999999 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-28 14:11 Message: Logged In: YES user_id=31435 Huh! My comment got lost. The patch looks good, but add 1 to `timet` instead of 1.0. We don't know whether the C time_t type is an integral or floating type, and using an integer literal works smoothly for both. For that matter, we don't know that time_t counts number of seconds either (e.g., perhaps it counts number of nanoseconds), but other code in Python assumes that it does, so there's no special sin in assuming it does here too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 13:32 Message: Logged In: YES user_id=849994 Really attaching a patch now. ;) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 13:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 From noreply at sourceforge.net Fri Apr 28 21:06:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 12:06:44 -0700 Subject: [ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion Message-ID: Bugs item #1478253, was opened at 2006-04-28 10:59 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) >Assigned to: Thomas Heller (theller) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 00003930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-04-28 21:06 Message: Logged In: YES user_id=11105 Gabriele, from the thread you mention I would assume that this patch may fix the problem for you - it should be applied to Lib/ctypes/test/test_find.py: Index: test_find.py =================================================================== --- test_find.py (Revision 45791) +++ test_find.py (Arbeitskopie) @@ -39,9 +39,9 @@ if lib_glu: self.glu = CDLL(lib_glu, RTLD_GLOBAL) if lib_glut: - self.glut = CDLL(lib_glut) + self.glut = CDLL(lib_glut, RTLD_GLOBAL) if lib_gle: - self.gle = CDLL(lib_gle) + self.gle = CDLL(lib_gle, RTLD_GLOBAL) if lib_gl: def test_gl(self): About the differences between ctypes in 2.5a1 and 2.5a2: Python 2.5a2's ctypes contained changes that I had better not made. This has been reverted in 2.5a2 version, which explains the large differences. FWIW, it seems all the Python buildbots and other systems that test the 2.5a2 code doen't have the problem that you report. Which does not mean that your system is broken, just that it is different (but similar to that one mentioned in the thread on ctypes-users from last October)! Please try the patch and report back. ---------------------------------------------------------------------- Comment By: balducci (balducci) Date: 2006-04-28 19:05 Message: Logged In: YES user_id=1452725 Dear Thomas, thank you for your reply. I've investigated a little bit more the problem. 2.5a1 worked smoothly on test_ctypes: this makes me think that the problem isn't in my box (it's an old redhat-7.1, but I keep all the system up-2-date: kernel,X11,glibc etc.). Also, I've kept python up-2-date since 2.3.4 and never seen this. On the other hand, it is also true that the (verbose mode) output of test_ctypes in 2.5a1, while showing a test_GL line, does not contain any test_glu and/or test_glut lines (which, together with test_gl, give the errors in 2.5a2): so it might also be that these new tests (test_glu and test_glut) make some local (i.e. due to my box) problem evident. However, I'm incline to think that there must be something in 2.5a2 which has changed from 2.5a1: => Lib/ctypes/__init__.py heavily differ from 2.5a1 to 2.5a2 (the error reported in the attached file I sent seems to have been generated in __init__.py) => also, the traceback in the attachment quotes a file Lib/ctypes/test/test_find.py, which I don't find in 2.5a1 => the error is quite reasonable: libglut.so.3 does not define XGetExtensionVersion, which is instead defined in libXi.so I seem to understand that exactly this kind of problem was reported in the following thread: http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534 I've seen just now that you got involved there! Well, as I said, I do not speak python, but from a glance to the thread I seem to understand that the problem could be in the use of RTLD_GLOBAL/RTLD_LOCAL (I don't know what these are for, but I guess that RTLD stands for RunTime Loader?) As I understand it, the problem seems to be as if one tries to compile a C program which calls XGetExtensionVersion with -lglut, but without -lXi. Perhaps the corresponding action should be done with test_ctypes, but I have no idea how this is done with python. I've also to admit that being the only one who has reported this problem on such a widespread platfrom like linux makes me perplexed. In the end, I don't know what to think: the problem is actually there and was not there with 2.5a1 (nor with any previous build since 2.3.4). I regret being unable to go deeper in this problem and I apoligize if this report is not clear enough. If there is any test I can do to make things clearer, please, just tell me. And THANK YOU for your work. Ciao Gabriele ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-28 17:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 From noreply at sourceforge.net Fri Apr 28 21:19:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 12:19:12 -0700 Subject: [ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given Message-ID: Bugs item #1473560, was opened at 2006-04-20 14:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 Please note that this 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 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.Request constructor to urllib.quote the url given Initial Comment: urllib2.Request('http://www.google.com/search?client=firefox&q=foo bar', None) this fails. it shouldn't ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 19:19 Message: Logged In: YES user_id=849994 I don't know what your problem is. This works perfectly for me: >>> r = urllib2.Request("http://www.google.com/search?client=firefox&q=foobar", None) >>> o = urllib2.HTTPHandler() >>> u = o.http_open(r) >>> u.read() "..." Closing as "Works for me". If you have another problem, please reopen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 From noreply at sourceforge.net Fri Apr 28 21:09:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Apr 2006 12:09:58 -0700 Subject: [ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error Message-ID: Bugs item #1478429, was opened at 2006-04-28 14:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 Please note that this 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 Submitted By: Erwin Bonsma (eriban) Assigned to: Georg Brandl (gbrandl) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..999999 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.99999976 microsecond must be in 0..999999 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 19:09 Message: Logged In: YES user_id=849994 Committed as rev. 45792, 45793, then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-28 18:11 Message: Logged In: YES user_id=31435 Huh! My comment got lost. The patch looks good, but add 1 to `timet` instead of 1.0. We don't know whether the C time_t type is an integral or floating type, and using an integer literal works smoothly for both. For that matter, we don't know that time_t counts number of seconds either (e.g., perhaps it counts number of nanoseconds), but other code in Python assumes that it does, so there's no special sin in assuming it does here too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Really attaching a patch now. ;) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 From noreply at sourceforge.net Sat Apr 29 13:34:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Apr 2006 04:34:15 -0700 Subject: [ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given Message-ID: Bugs item #1473560, was opened at 2006-04-20 17:02 Message generated for change (Comment added) made by nkour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 Please note that this 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 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.Request constructor to urllib.quote the url given Initial Comment: urllib2.Request('http://www.google.com/search?client=firefox&q=foo bar', None) this fails. it shouldn't ---------------------------------------------------------------------- >Comment By: Nikos Kouremenos (nkour) Date: 2006-04-29 14:34 Message: Logged In: YES user_id=865368 it's foo bar not foobar. and space should be automatcally become %20 (urllib.quote()) but it doesn't. please reopen ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 22:19 Message: Logged In: YES user_id=849994 I don't know what your problem is. This works perfectly for me: >>> r = urllib2.Request("http://www.google.com/search?client=firefox&q=foobar", None) >>> o = urllib2.HTTPHandler() >>> u = o.http_open(r) >>> u.read() "..." Closing as "Works for me". If you have another problem, please reopen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 From noreply at sourceforge.net Sat Apr 29 15:23:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Apr 2006 06:23:08 -0700 Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network drive Message-ID: Bugs item #1478529, was opened at 2006-04-28 16:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 13:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 From noreply at sourceforge.net Sat Apr 29 15:51:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Apr 2006 06:51:03 -0700 Subject: [ python-Bugs-1474677 ] non-keyword argument following keyword Message-ID: Bugs item #1474677, was opened at 2006-04-22 16:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 Please note that this 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 Submitted By: George Yoshida (quiver) Assigned to: Jeremy Hylton (jhylton) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 13:51 Message: Logged In: YES user_id=849994 Patch attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-25 05:48 Message: Logged In: YES user_id=33168 Confirmed 2.5 behaviour and regression from 2.[34]. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-25 05:47 Message: Logged In: YES user_id=33168 Jeremy, could you look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 From noreply at sourceforge.net Sun Apr 30 00:00:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Apr 2006 15:00:39 -0700 Subject: [ python-Bugs-1479099 ] 'compile' built-in function failures when missing EOL Message-ID: Bugs item #1479099, was opened at 2006-04-30 01:00 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=1479099&group_id=5470 Please note that this 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 Submitted By: Ori Peleg (oripel) Assigned to: Nobody/Anonymous (nobody) Summary: 'compile' built-in function failures when missing EOL Initial Comment: The 'compile' built-in function sometimes fails when given a source string that doesn't end in an EOL. The following example crashes Python 2.3, 2.4, and 2.5a1: prompt> ./python2.5 -c "compile('def foo(x):\n pass\n#abc', 'blah.py', 'exec')" Traceback (most recent call last): File "", line 1, in File "blah.py", line 3 #abc ^ SyntaxError: invalid syntax Attached is a patch to Lib/test/test_compile.py with a test for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479099&group_id=5470 From noreply at sourceforge.net Sun Apr 30 00:07:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Apr 2006 15:07:01 -0700 Subject: [ python-Bugs-1479099 ] 'compile' built-in function failures when missing EOL Message-ID: Bugs item #1479099, was opened at 2006-04-30 01:00 Message generated for change (Comment added) made by oripel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479099&group_id=5470 Please note that this 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 Submitted By: Ori Peleg (oripel) Assigned to: Nobody/Anonymous (nobody) Summary: 'compile' built-in function failures when missing EOL Initial Comment: The 'compile' built-in function sometimes fails when given a source string that doesn't end in an EOL. The following example crashes Python 2.3, 2.4, and 2.5a1: prompt> ./python2.5 -c "compile('def foo(x):\n pass\n#abc', 'blah.py', 'exec')" Traceback (most recent call last): File "", line 1, in File "blah.py", line 3 #abc ^ SyntaxError: invalid syntax Attached is a patch to Lib/test/test_compile.py with a test for this. ---------------------------------------------------------------------- >Comment By: Ori Peleg (oripel) Date: 2006-04-30 01:07 Message: Logged In: YES user_id=1131251 The case that led me to this was calling 'trace.find_executable_linenos' on source files with this condition. See also https://opensvn.csie.org/traccgi/testoob/trac.cgi/ticket/206 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479099&group_id=5470 From noreply at sourceforge.net Sun Apr 30 10:22:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 01:22:37 -0700 Subject: [ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr Message-ID: Bugs item #900898, was opened at 2004-02-20 06:51 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James Kruth (jk7) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr Initial Comment: If the Request object being used returns a URI with a port included (e.g. http://www.mysite.com:7777/index.html) If Request.get_full_url() or Request.get_host() returns a URI or host with a port included (e.g. http://www.mysite.com:7777/index.html or www.mysite.com:7777, respectively), and authentication (proxy or http, basic only) is required, then the respective AuthHandlers (HTTPBasicAuthHandler, ProxyBasicAuthHandler) end up calling http_error_auth_reqed with a host looking like "www.mysite.com:7777". http_error_auth_reqed then precedes to call retry_http_basic_auth with the same host parameter, which in turn calls HTTPPasswordMgr.find_user_password. The problem is that find_user_password appears to expect a full URI, and attempts to reduce it to just a host, by calling reduce_uri. If a bare host with a port is passed (like "www.mysite.com:7777"), then reduce_uri returns just the port number in the netloc position - which find_user_password then attempts to compare against the correct host name you've stored in your HTTPPasswordMgr object along with your user name and password. I believe either find_user_password should not reduce the host, or the Auth Handler objects should pass full hostnames to find_user_password. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 08:22 Message: Logged In: YES user_id=849994 Fixed with commit of patch 1470846. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 17:59 Message: Logged In: YES user_id=261020 This is fixed by patch 1470846, which includes tests and doc fix / update (though I neglected to mention that the patch fixes this problem in the initial patch comment; I'll rectify that now). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2004-04-06 19:58 Message: Logged In: YES user_id=4631 I ran into this problem today with Python 2.3.3 on RedHat 9. I'm using port numbers in my URLs, and I found that the Auth Handler did NOT correctly find the userid and password registered. ie: authinfo = urllib2.HTTPPasswordMgrWithDefaultRealm() authinfo.add_password(None, host, userid, password) authHandler = urllib2.HTTPBasicAuthHandler(authinfo) opener = urllib2.build_opener(authHandler) where host = "http://localhost:7993" I've tested the proposed fix shown in urllib2_bug.py at line 31, to whit, this: class HTTPBasicAuthHandlerF(AbstractBasicAuthHandler, BaseHandler): auth_header = 'Authorization' def http_error_401(self, req, fp, code, msg, headers): host = req.get_full_url() return self.http_error_auth_reqed('www-authenticate', host, req, headers) This appears to have corrected the problem. test_urllib2.py and test_urllib.py both pass after making this change. I did not test the ProxyBasicAuthHandler change (I don't have a proxy) ---------------------------------------------------------------------- Comment By: James Kruth (jk7) Date: 2004-02-20 21:25 Message: Logged In: YES user_id=979977 Here's a sample of the problem... ---------------------------------------------------------------------- Comment By: James Kruth (jk7) Date: 2004-02-20 14:39 Message: Logged In: YES user_id=979977 I've made up a file with some source code and comments that will hopefully clarify what I posted. I will post an example of the problem a bit later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470 From noreply at sourceforge.net Sun Apr 30 10:49:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 01:49:43 -0700 Subject: [ python-Bugs-1479226 ] test_inspect fails on WinXP (2.5a2) Message-ID: Bugs item #1479226, was opened at 2006-04-30 11: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=1479226&group_id=5470 Please note that this 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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect fails on WinXP (2.5a2) Initial Comment: test_inspect fails after installing 2.5a2 on WinXP Output of python -c "from test.test_inspect import test_main; test_main()" is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&group_id=5470 From noreply at sourceforge.net Sun Apr 30 10:51:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 01:51:50 -0700 Subject: [ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given Message-ID: Bugs item #1473560, was opened at 2006-04-20 14:02 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 Please note that this 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 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.Request constructor to urllib.quote the url given Initial Comment: urllib2.Request('http://www.google.com/search?client=firefox&q=foo bar', None) this fails. it shouldn't ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2006-04-29 11:34 Message: Logged In: YES user_id=865368 it's foo bar not foobar. and space should be automatcally become %20 (urllib.quote()) but it doesn't. please reopen ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 19:19 Message: Logged In: YES user_id=849994 I don't know what your problem is. This works perfectly for me: >>> r = urllib2.Request("http://www.google.com/search?client=firefox&q=foobar", None) >>> o = urllib2.HTTPHandler() >>> u = o.http_open(r) >>> u.read() "..." Closing as "Works for me". If you have another problem, please reopen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 From noreply at sourceforge.net Sun Apr 30 11:25:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 02:25:44 -0700 Subject: [ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given Message-ID: Bugs item #1473560, was opened at 2006-04-20 14:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Submitted By: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.Request constructor to urllib.quote the url given Initial Comment: urllib2.Request('http://www.google.com/search?client=firefox&q=foo bar', None) this fails. it shouldn't ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:25 Message: Logged In: YES user_id=849994 The docs say that the argument to the Request constructor must be a valid URL. A valid URL doesn't contain spaces, so the behavior is consistent. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2006-04-29 11:34 Message: Logged In: YES user_id=865368 it's foo bar not foobar. and space should be automatcally become %20 (urllib.quote()) but it doesn't. please reopen ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 19:19 Message: Logged In: YES user_id=849994 I don't know what your problem is. This works perfectly for me: >>> r = urllib2.Request("http://www.google.com/search?client=firefox&q=foobar", None) >>> o = urllib2.HTTPHandler() >>> u = o.http_open(r) >>> u.read() "..." Closing as "Works for me". If you have another problem, please reopen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470 From noreply at sourceforge.net Sun Apr 30 11:28:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 02:28:17 -0700 Subject: [ python-Bugs-1281692 ] urllib violates rfc 959 Message-ID: Bugs item #1281692, was opened at 2005-09-04 17:30 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 Please note that this 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 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:28 Message: Logged In: YES user_id=849994 Fixed by applying said patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 20:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1357260 reports the same issue for both urllib and urllib2. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-08 06:18 Message: Logged In: YES user_id=341410 "The pathname should specify a directory or other system-specific file group descriptor." If the system (ftp server) does not support a particular 'file name' as a 'file group descriptor', it seems to me that the system (ftp server) is braindead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 From noreply at sourceforge.net Sun Apr 30 11:28:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 02:28:58 -0700 Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable. Message-ID: Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this 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 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:28 Message: Logged In: YES user_id=849994 Fixed by applying said patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-15 20:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1281692 reports the same issue for the urllib case, and includes a reference to the RFC. ---------------------------------------------------------------------- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-17 05:38 Message: Logged In: YES user_id=1033842 File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd return self.getresp() File "/usr/lib/python2.4/ftplib.py", line 216, in getresp raise error_perm, resp IOError: [Errno ftp error] [Errno ftp error] 550 tompda_685692_Professional.Palm.OS.Programming.part12.rar: No such file or directory. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 13:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? ---------------------------------------------------------------------- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 From noreply at sourceforge.net Sun Apr 30 11:46:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 02:46:08 -0700 Subject: [ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion Message-ID: Bugs item #1478253, was opened at 2006-04-28 08:59 Message generated for change (Comment added) made by balducci You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Thomas Heller (theller) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 00003930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele ---------------------------------------------------------------------- >Comment By: balducci (balducci) Date: 2006-04-30 09:46 Message: Logged In: YES user_id=1452725 Dear Thomas, I thank you very much for your time and effort. I think I have solved the problem and, as I suspected, the problem was on my side and not on python's. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have two shared libglut's installed: one is from orginal RedHat-7.1 distro and the other was installed by me some time ago. Now, if I check dependencies of the two libs, I get: RedHat's libglut: ---------------- myhost> ldd /usr/lib/libglut.so linux-gate.so.1 => (0xffffe000) libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000) libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000) libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef0000) libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000) libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000) libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce0000) libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000) libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000) /usr/local/glibc/lib/ld-linux.so.2 (0x80000000) My libglut installation: ----------------------- myhost> ldd /usr/local/X11R6/lib/libglut.so linux-gate.so.1 => (0xffffe000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000) /usr/local/glibc/lib/ld-linux.so.2 (0x80000000) Things seem to be clear for me now: /usr/lib/libglut.so contains all the necessary dependencies to resolve any reference which is not defined in it, while /usr/local/X11R6/lib/libglut.so does not contain any dependency from the X11 libs, which instead is NEEDED (e.g. the XGetExtensionVersion problem shown up). In fact, if I run `LD_LIBRARY_PATH=/usr/lib make test', i.e. force runtime loader to use /usr/lib/libglut.so, everything works nicely, even without the patch you sent. On the other hand, if /usr/local/X11R6/lib/libglut.so is picked up, then the errors occur and your patch does not solve the problem (and it could not in any case, given the above, I guess). Going back to my libglut installation notes, I could verify that no X11 dependencies were compiled in (most probably due to some misconfiguration by me). In the end, I think you can close this (which is not a) bug. I apologize once again for wasting your time on an issue which I could have investigated more deeply before claiming a bug in python. THANK YOU and ciao Gabriele ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-28 19:06 Message: Logged In: YES user_id=11105 Gabriele, from the thread you mention I would assume that this patch may fix the problem for you - it should be applied to Lib/ctypes/test/test_find.py: Index: test_find.py =================================================================== --- test_find.py (Revision 45791) +++ test_find.py (Arbeitskopie) @@ -39,9 +39,9 @@ if lib_glu: self.glu = CDLL(lib_glu, RTLD_GLOBAL) if lib_glut: - self.glut = CDLL(lib_glut) + self.glut = CDLL(lib_glut, RTLD_GLOBAL) if lib_gle: - self.gle = CDLL(lib_gle) + self.gle = CDLL(lib_gle, RTLD_GLOBAL) if lib_gl: def test_gl(self): About the differences between ctypes in 2.5a1 and 2.5a2: Python 2.5a2's ctypes contained changes that I had better not made. This has been reverted in 2.5a2 version, which explains the large differences. FWIW, it seems all the Python buildbots and other systems that test the 2.5a2 code doen't have the problem that you report. Which does not mean that your system is broken, just that it is different (but similar to that one mentioned in the thread on ctypes-users from last October)! Please try the patch and report back. ---------------------------------------------------------------------- Comment By: balducci (balducci) Date: 2006-04-28 17:05 Message: Logged In: YES user_id=1452725 Dear Thomas, thank you for your reply. I've investigated a little bit more the problem. 2.5a1 worked smoothly on test_ctypes: this makes me think that the problem isn't in my box (it's an old redhat-7.1, but I keep all the system up-2-date: kernel,X11,glibc etc.). Also, I've kept python up-2-date since 2.3.4 and never seen this. On the other hand, it is also true that the (verbose mode) output of test_ctypes in 2.5a1, while showing a test_GL line, does not contain any test_glu and/or test_glut lines (which, together with test_gl, give the errors in 2.5a2): so it might also be that these new tests (test_glu and test_glut) make some local (i.e. due to my box) problem evident. However, I'm incline to think that there must be something in 2.5a2 which has changed from 2.5a1: => Lib/ctypes/__init__.py heavily differ from 2.5a1 to 2.5a2 (the error reported in the attached file I sent seems to have been generated in __init__.py) => also, the traceback in the attachment quotes a file Lib/ctypes/test/test_find.py, which I don't find in 2.5a1 => the error is quite reasonable: libglut.so.3 does not define XGetExtensionVersion, which is instead defined in libXi.so I seem to understand that exactly this kind of problem was reported in the following thread: http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534 I've seen just now that you got involved there! Well, as I said, I do not speak python, but from a glance to the thread I seem to understand that the problem could be in the use of RTLD_GLOBAL/RTLD_LOCAL (I don't know what these are for, but I guess that RTLD stands for RunTime Loader?) As I understand it, the problem seems to be as if one tries to compile a C program which calls XGetExtensionVersion with -lglut, but without -lXi. Perhaps the corresponding action should be done with test_ctypes, but I have no idea how this is done with python. I've also to admit that being the only one who has reported this problem on such a widespread platfrom like linux makes me perplexed. In the end, I don't know what to think: the problem is actually there and was not there with 2.5a1 (nor with any previous build since 2.3.4). I regret being unable to go deeper in this problem and I apoligize if this report is not clear enough. If there is any test I can do to make things clearer, please, just tell me. And THANK YOU for your work. Ciao Gabriele ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-28 15:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 From noreply at sourceforge.net Sun Apr 30 11:51:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 02:51:57 -0700 Subject: [ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion Message-ID: Bugs item #1478253, was opened at 2006-04-28 08:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 Please note that this 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: Closed >Resolution: Invalid Priority: 5 Submitted By: balducci (balducci) Assigned to: Thomas Heller (theller) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 00003930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 09:51 Message: Logged In: YES user_id=849994 Closing. Thank you for your thorough investigation. ---------------------------------------------------------------------- Comment By: balducci (balducci) Date: 2006-04-30 09:46 Message: Logged In: YES user_id=1452725 Dear Thomas, I thank you very much for your time and effort. I think I have solved the problem and, as I suspected, the problem was on my side and not on python's. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have two shared libglut's installed: one is from orginal RedHat-7.1 distro and the other was installed by me some time ago. Now, if I check dependencies of the two libs, I get: RedHat's libglut: ---------------- myhost> ldd /usr/lib/libglut.so linux-gate.so.1 => (0xffffe000) libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000) libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000) libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef0000) libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000) libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000) libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce0000) libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000) libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000) /usr/local/glibc/lib/ld-linux.so.2 (0x80000000) My libglut installation: ----------------------- myhost> ldd /usr/local/X11R6/lib/libglut.so linux-gate.so.1 => (0xffffe000) libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000) libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000) /usr/local/glibc/lib/ld-linux.so.2 (0x80000000) Things seem to be clear for me now: /usr/lib/libglut.so contains all the necessary dependencies to resolve any reference which is not defined in it, while /usr/local/X11R6/lib/libglut.so does not contain any dependency from the X11 libs, which instead is NEEDED (e.g. the XGetExtensionVersion problem shown up). In fact, if I run `LD_LIBRARY_PATH=/usr/lib make test', i.e. force runtime loader to use /usr/lib/libglut.so, everything works nicely, even without the patch you sent. On the other hand, if /usr/local/X11R6/lib/libglut.so is picked up, then the errors occur and your patch does not solve the problem (and it could not in any case, given the above, I guess). Going back to my libglut installation notes, I could verify that no X11 dependencies were compiled in (most probably due to some misconfiguration by me). In the end, I think you can close this (which is not a) bug. I apologize once again for wasting your time on an issue which I could have investigated more deeply before claiming a bug in python. THANK YOU and ciao Gabriele ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-28 19:06 Message: Logged In: YES user_id=11105 Gabriele, from the thread you mention I would assume that this patch may fix the problem for you - it should be applied to Lib/ctypes/test/test_find.py: Index: test_find.py =================================================================== --- test_find.py (Revision 45791) +++ test_find.py (Arbeitskopie) @@ -39,9 +39,9 @@ if lib_glu: self.glu = CDLL(lib_glu, RTLD_GLOBAL) if lib_glut: - self.glut = CDLL(lib_glut) + self.glut = CDLL(lib_glut, RTLD_GLOBAL) if lib_gle: - self.gle = CDLL(lib_gle) + self.gle = CDLL(lib_gle, RTLD_GLOBAL) if lib_gl: def test_gl(self): About the differences between ctypes in 2.5a1 and 2.5a2: Python 2.5a2's ctypes contained changes that I had better not made. This has been reverted in 2.5a2 version, which explains the large differences. FWIW, it seems all the Python buildbots and other systems that test the 2.5a2 code doen't have the problem that you report. Which does not mean that your system is broken, just that it is different (but similar to that one mentioned in the thread on ctypes-users from last October)! Please try the patch and report back. ---------------------------------------------------------------------- Comment By: balducci (balducci) Date: 2006-04-28 17:05 Message: Logged In: YES user_id=1452725 Dear Thomas, thank you for your reply. I've investigated a little bit more the problem. 2.5a1 worked smoothly on test_ctypes: this makes me think that the problem isn't in my box (it's an old redhat-7.1, but I keep all the system up-2-date: kernel,X11,glibc etc.). Also, I've kept python up-2-date since 2.3.4 and never seen this. On the other hand, it is also true that the (verbose mode) output of test_ctypes in 2.5a1, while showing a test_GL line, does not contain any test_glu and/or test_glut lines (which, together with test_gl, give the errors in 2.5a2): so it might also be that these new tests (test_glu and test_glut) make some local (i.e. due to my box) problem evident. However, I'm incline to think that there must be something in 2.5a2 which has changed from 2.5a1: => Lib/ctypes/__init__.py heavily differ from 2.5a1 to 2.5a2 (the error reported in the attached file I sent seems to have been generated in __init__.py) => also, the traceback in the attachment quotes a file Lib/ctypes/test/test_find.py, which I don't find in 2.5a1 => the error is quite reasonable: libglut.so.3 does not define XGetExtensionVersion, which is instead defined in libXi.so I seem to understand that exactly this kind of problem was reported in the following thread: http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534 I've seen just now that you got involved there! Well, as I said, I do not speak python, but from a glance to the thread I seem to understand that the problem could be in the use of RTLD_GLOBAL/RTLD_LOCAL (I don't know what these are for, but I guess that RTLD stands for RunTime Loader?) As I understand it, the problem seems to be as if one tries to compile a C program which calls XGetExtensionVersion with -lglut, but without -lXi. Perhaps the corresponding action should be done with test_ctypes, but I have no idea how this is done with python. I've also to admit that being the only one who has reported this problem on such a widespread platfrom like linux makes me perplexed. In the end, I don't know what to think: the problem is actually there and was not there with 2.5a1 (nor with any previous build since 2.3.4). I regret being unable to go deeper in this problem and I apoligize if this report is not clear enough. If there is any test I can do to make things clearer, please, just tell me. And THANK YOU for your work. Ciao Gabriele ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-04-28 15:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 From noreply at sourceforge.net Sun Apr 30 12:10:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 03:10:30 -0700 Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network drive Message-ID: Bugs item #1478529, was opened at 2006-04-28 18:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-04-30 12:10 Message: Logged In: YES user_id=21627 What version of Windows are you using? Do you know of any documentation of this limit? (without actually testing, I find it hard to believe that this limit exists in Windows) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 15:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 From noreply at sourceforge.net Sun Apr 30 13:52:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 04:52:49 -0700 Subject: [ python-Bugs-1110705 ] list comprehension scope Message-ID: Bugs item #1110705, was opened at 2005-01-27 14:27 Message generated for change (Comment added) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Please note that this 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.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined ---------------------------------------------------------------------- Comment By: Christoph Zwerschke (cito) Date: 2006-04-30 13:52 Message: Logged In: YES user_id=193957 Either this is a bug that should be fixed, or the documentation that says it is a bug should be fixed (http://www.python.org/doc/current/ref/lists.html#foot4519). That fact that an ordinary for loop leaks the control variables into the containing scope may be a design feature, but the same behavior for list comprehensions can hardly be called a design feature. At least not one that is reasonable. I would rather call it a bug. It definitely contradicts the principle of least surprise. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:54 Message: Logged In: YES user_id=341410 "this behavior is deprecated, and relying on it will not work once this bug is fixed in a future release" As we have not yet reached the future release in which this will happen, and the 'bug' is both known and documented, it will be 'fixed' when it is fixed. The reason that it has not yet been 'fixed' is because there is a nontrivial amount of code that would break if it was. I personally would call it a deprecated 'feature'. Then again, I use it more often than I should. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-01-27 15:11 Message: Logged In: YES user_id=750513 Seemingly (according to: http://docs.python.org/ref/lists.html) this is indeed a bug that should be fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 14:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 From noreply at sourceforge.net Sun Apr 30 18:23:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 09:23:16 -0700 Subject: [ python-Bugs-1478529 ] size limit exceeded for read() from network drive Message-ID: Bugs item #1478529, was opened at 2006-04-28 12:46 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-04-30 12:23 Message: Logged In: YES user_id=31435 Martin, here's an MS article seemingly related to this: http://support.microsoft.com/default.aspx?scid=kb;en-us;899149 However, it's about writing to a file on a network drive, not reading from it. It says that opening the file in 'w+b' mode, instead of 'wb' mode, is a workaround. I couldn't find anything documenting the same kind of problem for reading. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-30 06:10 Message: Logged In: YES user_id=21627 What version of Windows are you using? Do you know of any documentation of this limit? (without actually testing, I find it hard to believe that this limit exists in Windows) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 09:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 From noreply at sourceforge.net Sun Apr 30 19:43:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 10:43:25 -0700 Subject: [ python-Bugs-1479226 ] test_inspect fails on WinXP (2.5a2) Message-ID: Bugs item #1479226, was opened at 2006-04-30 08:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&group_id=5470 Please note that this 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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect fails on WinXP (2.5a2) Initial Comment: test_inspect fails after installing 2.5a2 on WinXP Output of python -c "from test.test_inspect import test_main; test_main()" is attached. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 17:43 Message: Logged In: YES user_id=849994 Thanks for reporting! This was caused by a bug in inspect.py which is was fixed in revisions 45822 and 45824. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&group_id=5470 From noreply at sourceforge.net Sun Apr 30 21:52:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 12:52:46 -0700 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this 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 Submitted By: cheops (atila-cheops) Assigned to: Peter ? strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 19:52 Message: Logged In: YES user_id=849994 The error causing "_active.remove(self)" call was removed from wait() with patch 1467770, so I think this is fixed. ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-11 20:10 Message: Logged In: YES user_id=1276121 there are 2 definitions of the function poll, one for windows and one for POSIX systems in the windows version _deadlock is not used in the POSIX version _deadlock is used see also modification made by loewis in committed version 45234 ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-04-11 07:21 Message: Logged In: YES user_id=1434251 I looked at the patch #1467770 you mentioned and downloaded the patch. Is it correct that _deadlock variable is used in the definition of poll but it is not in the argument list? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:57 Message: Logged In: YES user_id=1276121 see patch #1467770 ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:50 Message: Logged In: YES user_id=1488657 > Simply list operations such as remove() and append() are > thread safe, OK, my apologies... I did not know. I did some more tests. On Linux, I found lots of: File "./subprocess.py", line 428, in call return Popen(*args, **kwargs).wait() File "./subprocess.py", line 1023, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes The try...except solution does not handle this (since we are in the "posix" section). In my opinion, the call to _cleanup() in Popen.__init__() is useless (it just checks if older processes have stopped when a new one is started. I cannot see why it could be mandatory) and it is the root of this bug. I commented it out (line 506) and retried my tests on Linux & Windows plateforms: I had no exception at all. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2006-03-29 05:11 Message: Logged In: YES user_id=344921 >I think accesses to _active should be serialized in a >thread-safe way. _active could be a Queue (from the Queue >module) for example Simply list operations such as remove() and append() are thread safe, so there should be no need for a Queue. Also, a Queue cannot be used since the subprocess module needs to be compatible with Python 2.2. ---------------------------------------------------------------------- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-28 23:17 Message: Logged In: YES user_id=1488657 I am running into the same problem on a Windows 2k/XP plateform with a multi-threaded application. It occurs randomly. It has never appened (yet) on a Linux plateform. I think accesses to _active should be serialized in a thread-safe way. _active could be a Queue (from the Queue module) for example. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-25 08:10 Message: Logged In: YES user_id=1434251 Wouldn't it be best to completely remove any references to "_active" and "_cleanup"? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-01-25 07:08 Message: Logged In: YES user_id=1276121 As suggested by astrand adding a try ... except clause in the file subprocess.py did the job I had to add that try ... except clause in 2 places if you look in the file there are 2 instances were list.remove(x) occurs unprotected. try: list.remove(x) except: pass I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three needed the patch. Hope this helps. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ? strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Sun Apr 30 22:20:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Apr 2006 13:20:48 -0700 Subject: [ python-Bugs-1385040 ] compiler module does not detect a syntax error Message-ID: Bugs item #1385040, was opened at 2005-12-19 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=1385040&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Jeremy Hylton (jhylton) Summary: compiler module does not detect a syntax error Initial Comment: import compiler compiler.parse("def foo(a=1,b): pass") Gives: Module(None, Stmt([Function(None, 'foo', ['a', 'b'], [Const(1)], 0, None, Stmt([Pass()]))])) However, the python interpreter itself barks for the same code: SyntaxError: non-default argument follows default argument -Harri ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 20:20 Message: Logged In: YES user_id=849994 Attaching patch. Please review. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-25 21:59 Message: Logged In: YES user_id=33168 FYI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470