From noreply@sourceforge.net Fri Nov 1 02:03:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 18:03:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 1 04:09:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 20:09:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 22:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 1 10:14:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 02:14:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-631713 ] test_frozen contains illegal raise stmts Message-ID: Bugs item #631713, was opened at 2002-10-31 19:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631713&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Finn Bock (bckfnn) >Assigned to: Finn Bock (bckfnn) Summary: test_frozen contains illegal raise stmts Initial Comment: The tests in test_frozen attempts to raise an exeption with a 3. argument that isn't a traceback obj (or none): try: import __hello__ except ImportError, x: raise TestFailed, "import __hello__ failed:", x If the import fails (for some reason) the TestFailed exception isn't raised but TypeError is raised instead: TypeError: raise: arg 3 must be a traceback or None ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-01 10:14 Message: Logged In: YES user_id=6656 You're right. Just fix it, please! I'm guessing it should be raise TestFailed("import __hello__ failed:", x) or something, but I don't think it's that important ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631713&group_id=5470 From noreply@sourceforge.net Fri Nov 1 11:34:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 03:34:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-631713 ] test_frozen contains illegal raise stmts Message-ID: Bugs item #631713, was opened at 2002-10-31 20:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631713&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Finn Bock (bckfnn) Assigned to: Finn Bock (bckfnn) Summary: test_frozen contains illegal raise stmts Initial Comment: The tests in test_frozen attempts to raise an exeption with a 3. argument that isn't a traceback obj (or none): try: import __hello__ except ImportError, x: raise TestFailed, "import __hello__ failed:", x If the import fails (for some reason) the TestFailed exception isn't raised but TypeError is raised instead: TypeError: raise: arg 3 must be a traceback or None ---------------------------------------------------------------------- >Comment By: Finn Bock (bckfnn) Date: 2002-11-01 12:34 Message: Logged In: YES user_id=4201 Fixed in test_frozen.py: 1.3; ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-01 11:14 Message: Logged In: YES user_id=6656 You're right. Just fix it, please! I'm guessing it should be raise TestFailed("import __hello__ failed:", x) or something, but I don't think it's that important ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631713&group_id=5470 From noreply@sourceforge.net Fri Nov 1 18:50:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 10:50:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-632196 ] Use type(x) is ... instead of type(x) == Message-ID: Bugs item #632196, was opened at 2002-11-01 12:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632196&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Use type(x) is ... instead of type(x) == Initial Comment: The sample code for type(object) should be: >>> if type(x) is types.StringType: print "It's a string" Instead of the older, deprecated idiom: >>> if type(x) == types.StringType: print "It's a string" This is the page I'm referencing: http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-57 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632196&group_id=5470 From noreply@sourceforge.net Fri Nov 1 20:18:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 12:18:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- Comment By: Bill Noon (bnoon) Date: 2002-11-01 15:18 Message: Logged In: YES user_id=298547 I just used the patch to fix problems with Quixote. Seems to have done the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-10 05:38 Message: Logged In: YES user_id=6656 Ah good. Will wait for your comments. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 18:27 Message: Logged In: YES user_id=31392 I'm listening, but it's going in one ear and out the other. I hope to have time for this later in the week. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 08:54 Message: Logged In: YES user_id=6656 Here's a patch that lets me compile the standard library and test suite with the compiler package and then run the test suite successfully. It does... oh, lots and lots of stuff. Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 06:08 Message: Logged In: YES user_id=6656 Here's a patch. Remarkably, it's just a one line patch to work around the SET_LINENO breakage. Other changes: * open the file for compiling in universal newlines mode. * always write the mtime to a .pyc little-endian-wise (2.2.2 candidate) * it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate) * bodge the parsermodule to return the encoding along with the encoding_decl non-terminal (this is pretty icky!) * let transformer cope with new 'testlist1' non-terminal * have transformer pick up the encoding declaration Still to do is using the encoding declaration to decode string literals. I think there should be an accessible from Python function to do this -- I really don't want to have to translate compile.c:parsestr into Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 05:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 11:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 05:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 12:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 05:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Fri Nov 1 21:35:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 13:35:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-632196 ] Use type(x) is ... instead of type(x) == Message-ID: Bugs item #632196, was opened at 2002-11-01 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632196&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Use type(x) is ... instead of type(x) == Initial Comment: The sample code for type(object) should be: >>> if type(x) is types.StringType: print "It's a string" Instead of the older, deprecated idiom: >>> if type(x) == types.StringType: print "It's a string" This is the page I'm referencing: http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-57 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-01 16:35 Message: Logged In: YES user_id=3066 Fixed, and added some additional clarifications, in Doc/lib/libfuncs.tex revisions 1.119 and 1.100.4.13. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632196&group_id=5470 From noreply@sourceforge.net Fri Nov 1 22:39:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 14:39:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter (?) refct (?) bug Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter (?) refct (?) bug Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:40:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:40:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-456398 ] strange IRIX test_re/test_sre failure Message-ID: Bugs item #456398, was opened at 2001-08-29 00:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470 >Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 4 Submitted By: Andrew Dalke (dalke) Assigned to: Fredrik Lundh (effbot) Summary: strange IRIX test_re/test_sre failure Initial Comment: The test_re and test_sre regression tests cause a core dump with the CVS version of Python. If I run the file directly I don't get the core dump. test_pyclbr test_pyexpat test test_pyexpat skipped -- No module named pyexpat test_quopri test_re make: *** [test] Segmentation fault (core dumped) ./python -E -tt ./Lib/test/regrtest.py -l ^C % % ./python -E -tt ./Lib/test/test_re.py Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite % This is under an IRIX 6.4 machine, which is several years old. Python is compiled with gcc 2.95.2 but using the vendor's assembler. The assembler is also out of date. There were known problems with in 1.5.2 where the optimizer broke the pcre module. So I recompiled _sre.c with "-g". That did not fix the problem. Here's the stack trace from the core file. > 0 mark_save(state = , lo = , hi = ) ["/usr2/people/dalke/cvses/python/dist/src/./Modules/_s re.c":280, 0x100a1e 2c] 1 sre_match(state = 0x7fff1200, pattern = 0x104ec55a, level = 1357) ["/usr2/peo ple/dalke/cvses/python/dist/src/Modules/_sre.c":1053, 0x100a44b4] 2 sre_match(state = 0x7fff1200, pattern = 0x104ec55a, level = 1356) ["/usr2/peo ple/dalke/cvses/python/dist/src/Modules/_sre.c":1057, 0x100a4504] Guessing it's in the "recursion limit" test. I don't know if the problem is in _sre.c or in the IRIX libraries. I don't have access to a newer version of IRIX. I tried to force the core dump to occur without having to go through the whole regression suite. That doesn't work, which is itself suspecious. % ./python -E -tt ./Lib/test/regrtest.py -l test_re test_re 1 test OK. % ./python -E -tt ./Lib/test/regrtest.py -l test_array test_re test_array test_re All 2 tests OK. % ./python -E -tt ./Lib/test/regrtest.py -l test_array test_re test_re test_array test_re test_re All 3 tests OK. % I get the same failures with test_sre. Andrew dalke@dalkescientific.com ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:40 Message: Logged In: YES user_id=33168 Andrew, is this still a problem? How big is the stack? Could the problem have been that the max stack size was exceeded which caused the crash? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:42:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:42:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-530163 ] fpectl build on solaris: -lsunmath Message-ID: Bugs item #530163, was opened at 2002-03-14 22:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470 >Category: Build >Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: fpectl build on solaris: -lsunmath Initial Comment: This is on Solaris 2.7, with gcc2.95.2 Observed on both the trunk and the release22 branch. By default, the configure/setup stuff isn't including -L/opt/SUNWspro/lib -R/opt/SUNWspro/lib -lsunmath when linking fpectl.so. This means that this doesn't produce a working module (it needs libsunmath for ieee_handler) My autoconf knowledge isn't excellent, but I'm going to have a look-see, figure out the easiest way to do this... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-15 04:22 Message: Logged In: YES user_id=21627 I think there is absolutely no way to find SUNWspro reliably. /opt is but one location where it might be installed - on our infrastructure, it is not in /opt, since that is not NFS shared. If c89 is on the path, it could give an indication where SUNWspro may be installed. In any case, I recommend to perform the necessary computation in setup.py, not in autoconf. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:44:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:44:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-542314 ] long file name support broken in windows Message-ID: Bugs item #542314, was opened at 2002-04-11 00:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470 >Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: long file name support broken in windows Initial Comment: >From c.l.py, thread "" Peter D: I'm using windows and trying to call os.path.getmtime () after using os.path.walk... However, I'm choking with "[Errno 38] Filename too long" on paths with len > ~260 Adding Martin's reply in a new comment (so it is not at the top of each and every mail I get on this bug :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-04-11 00:26 Message: Logged In: YES user_id=14198 Martin v. Loewis's reply on c.l.py: Since you are asking for a work-around: cd into one of the more nested directories when the path gets longer (os.chdir), and use relative paths from then on. If you want to study how to solve the problem: the relevant code snippet is in Modules/posixmodule.c /* the library call can blow up if the file name is too long! */ if (pathlen > MAX_PATH) { PyMem_Free(pathfree); errno = ENAMETOOLONG; return posix_error(); } There might be different ways to approach this: - challenge the correctness of the comment: - try to establish why the author of that code thought that the C library could blow up - analyse whether these arguments are still true with the current compiler version -or- - prove the argument wrong by analysing the source code of the C library - then remove the constraint -or- - use different API to achieve the same effect without suffering from the constraint. I'm serious about these suggestions: users would appreciate if this gets fixed somehow - apparently, the system allows longer file names, and apparently, the system itself can deal with that quite well. This can be only true if the system either doesn't use its C library, or if the C library does not have this restriction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:45:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:45:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python Message-ID: Bugs item #542482, was opened at 2002-04-11 08:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470 >Category: Build >Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) Summary: Problem compiling Python Initial Comment: Hi, I try to compile Python-2.2.1 on my linux slackware 8 with gcc-3.0.4 there was no problem with the configure, but for the make i got this : # gmake gcc -c -DNDEBUG -g -O3 -march=i686 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/thread.o Python/thread.c In file included from Python/thread.c:109: Python/thread_pth.h: In function `PyThread_start_new_thread': Python/thread_pth.h:59: warning: return makes integer from pointer without a cast In file included from Python/thread.c:113: Python/thread_pthread.h:113:1: warning: "CHECK_STATUS" redefined Python/thread_pth.h:31:1: warning: this is the location of the previous definition In file included from Python/thread.c:113: Python/thread_pthread.h: At top level: Python/thread_pthread.h:139: redefinition of `PyThread__init_thread' Python/thread_pth.h:38: `PyThread__init_thread' previously defined here Python/thread_pthread.h:154: redefinition of `PyThread_start_new_thread' Python/thread_pth.h:48: `PyThread_start_new_thread' previously defined here Python/thread_pthread.h:235: redefinition of `PyThread_get_thread_ident' Python/thread_pth.h:63: `PyThread_get_thread_ident' previously defined here Python/thread_pthread.h:250: redefinition of `do_PyThread_exit_thread' Python/thread_pth.h:73: `do_PyThread_exit_thread' previously defined here Python/thread_pthread.h:262: redefinition of `PyThread_exit_thread' Python/thread_pth.h:84: `PyThread_exit_thread' previously defined here Python/thread_pthread.h:268: redefinition of `PyThread__exit_thread' Python/thread_pth.h:89: `PyThread__exit_thread' previously defined here Python/thread_pthread.h:302: redefinition of `PyThread_allocate_lock' Python/thread_pth.h:119: `PyThread_allocate_lock' previously defined here Python/thread_pthread.h:335: redefinition of `PyThread_free_lock' Python/thread_pth.h:145: `PyThread_free_lock' previously defined here Python/thread_pthread.h:352: redefinition of `PyThread_acquire_lock' Python/thread_pth.h:154: `PyThread_acquire_lock' previously defined here Python/thread_pthread.h:390: redefinition of `PyThread_release_lock' Python/thread_pth.h:191: `PyThread_release_lock' previously defined here Python/thread_pthread.h:413: redefinition of `struct semaphore' Python/thread_pthread.h:421: redefinition of `PyThread_allocate_sema' Python/thread_pth.h:221: `PyThread_allocate_sema' previously defined here Python/thread_pthread.h:449: redefinition of `PyThread_free_sema' Python/thread_pth.h:246: `PyThread_free_sema' previously defined here Python/thread_pthread.h:463: redefinition of `PyThread_down_sema' Python/thread_pth.h:254: `PyThread_down_sema' previously defined here Python/thread_pthread.h:493: redefinition of `PyThread_up_sema' Python/thread_pth.h:283: `PyThread_up_sema' previously defined here gmake: *** [Python/thread.o] Error 1 It would be great if you could help me with this ! Best regards, Pierre. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:45 Message: Logged In: YES user_id=33168 Is this still a problem w/2.2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 19:04 Message: Logged In: YES user_id=21627 You are right; this is the intention. It turns out that a configuration of an alternate thread library is not supported if pthreads are also available on the system. I'll try to come up with a work-around, but this is not high-priority, and may take a while. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-13 09:18 Message: Logged In: YES user_id=512388 I did ./configure --with-threads --with-pth I thought it means "enable thread support, and for this use gnu pth". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 04:31 Message: Logged In: YES user_id=21627 I think I can see the problem now. For some reason, Python tries to use both GNU pth and pthreads for threading; this cannot work. How did you invoke configure? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-12 22:29 Message: Logged In: YES user_id=512388 In fact i can't attach the file thread.i, it is too big :( ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2002-04-12 22:26 Message: Logged In: YES user_id=512388 Ok i have done : root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3 -march=i686 -Wall -Wstrict-prototypes -dD --save-temps --trace-includes -I. -I./Include -DHAVE_CONFIG_H -o Python/thread.o Python/thread.c >& compile.log I attach you the file compile.log and the file thread.i ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-11 17:59 Message: Logged In: YES user_id=21627 Can you please add the options "-dD --save-temps --trace-includes" to the gcc invocation, and attach both the compiler (error) output and thread.i to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:47:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:47:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-545410 ] corefile: python 2.1.3, zope 2.5.0 Message-ID: Bugs item #545410, was opened at 2002-04-17 19:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470 Category: None >Group: Python 2.1.2 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Geoff Gerrietts (ggerrietts) Assigned to: Nobody/Anonymous (nobody) Summary: corefile: python 2.1.3, zope 2.5.0 Initial Comment: I regularly get a corefile out of Zope 2.5.0, running on RedHat 6.2 and Python 2.1.3, usually within 5 or 6 page views. Reproducing the problem requires (for me) starting up Zope, going to the management interface, and bouncing around on a few of the different objects. Sometimes the first attempt to render the page will cause a crash, but sometimes it takes a few clicks. After the crash, Zope dumps core and politely restarts itself. Traceback files are largely the same from one crash to the next, with the only variation I've noted being the addresses of variables -- this fits with the fact that it takes a different number of steps each time. Traceback files (infuriatingly enough) do not show line number information for select.so, even though selectmodule.o was compiled with -g specified. Examination of the traceback shows that in stack frame 2, print ((PyCFunctionObject *)func) -> m_ml -> ml_name reveals "select". In that same frame, print ((PyObject *)arg) -> ob_type -> tp_name yields "Cannot access memory at address 0x1f". One traceback has been provided. Others, and other info, available on request. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:47 Message: Logged In: YES user_id=33168 Closing as Geoff says it's not a python bug. ---------------------------------------------------------------------- Comment By: Geoff Gerrietts (ggerrietts) Date: 2002-07-25 13:59 Message: Logged In: YES user_id=66989 I'm embarrassed to note that I forgot to close this bug when the resolution was discovered. It was, as many suggested, a defect in a third party extension -- in this case, a very old bug in ILU. Linux threading was making it look like the problem was occurring elsewhere. Hoping to submit that patch back against ILU very soon. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-25 12:11 Message: Logged In: YES user_id=31392 Are you still having this problem? If so, I would recommend trying to reproduce the crash with Zope 2.6 alpha 1 and a Python 2.1.3 or 2.2.1 debug build (configure --with-pydebug). ---------------------------------------------------------------------- Comment By: Geoff Gerrietts (ggerrietts) Date: 2002-04-24 20:47 Message: Logged In: YES user_id=66989 MALLOC_CHECK_ didn't do anything different for me. I don't know what that means exactly, because it definitely SEEMS like there's some bad memory management going on. Maybe it's just not bad ENOUGH. The arg in stackframe 2 is actually NOT in the shared library space -- the highest shared library address is actually in the 0x404xxxx range. I'm not sure how the programs are linked/run, so I'm not sure what 0x405d7ffc would likely be if it's not shared libraries, though. I've been looking into (and continue to look into) the possibility Guido suggested on python-dev, that this is an overrun of a thread's stack. It seems unlikely, given that stack threads are allotted 2MB under Linux, but I suppose anything's possible. The Data.fs in use in this core is 180MB; when compressed, it shrinks to about 90MB. It's a big site, so overruns are a lot more possible here than in other places. I'm going to take a pass at pulling out all the 3rd-party extension modules, but that's going to be very challenging. A significant part of the architecture (roughly half, including authentication) is accessible only through a 3rd party extension, ILU. My independent testing with ILU indicates that ILU works acceptably and doesn't cause memory corruption. Because it's so ingrained into the site, I'm going to look at doing more thorough testing and more of it, and I'll try to isolate it so I can test around it, but I don't think it's reasonable to try to replace it at this point in time; the engineering effort would be several weeks. There are (at least one) other 3rd party module(s) that I'll be able to rip out or fake up more easily. I think this is more of a progress report than anything else. Thanks for the eyes. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-19 10:50 Message: Logged In: YES user_id=31392 Are you using any third party Python extension modules with Zope? It may be a memory corruption problem in an extension. If you are, you should try to reproduce the problem with *only* Zope's core extensions and Python 2.1.3. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-18 01:44 Message: Logged In: YES user_id=21627 In that backtrace, it is clear that arg in stackframe 2 is bogus: 0x405d7ffc points into an area that appears to be used for shared libraries (please do "info shared" to support this theory). Now, arg presumably is the return value of load_args, where it was created through PyTuple_New. This suggests that the memory management got corrupted; something that likely happened much earlier. I recommend to set MALLOC_CHECK_ before starting Python. The documentation in malloc(3) says that setting it to 2 will cause an abort() when an error is found; from expecting the implementation, it appears that setting it to 3 will combine the debug traces printed and the call to abort; please experiment with all three values (1,2,3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:48:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:48:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-580107 ] Subclassing WeakValueDictionary impossib Message-ID: Bugs item #580107, was opened at 2002-07-11 10:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=580107&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Subclassing WeakValueDictionary impossib Initial Comment: I'm trying to subclass weakref.WeakValueDictionary, so that it can send notifications when keys are removed. I subclassed it and implemented a new __delitem__ method, but unfortunately this is not called because WeakValueDictionary manipulates UserDict's data member directly (in __makeremove), without calling the __delitem__ method. Inspection of the sources shows that this is also the case in other methods as well... I finally overrided __makeremovemethod _and_ __delitem__ ;-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=580107&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:50:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:50:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-605818 ] python-mode.el replaces function on f1 Message-ID: Bugs item #605818, was opened at 2002-09-06 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 >Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Toneby (toneby) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode.el replaces function on f1 Initial Comment: I've customized my global-keymap to save on F1, but python-mode overrides this and opens help. You should check if F1 is bound to something other than default, if it is you shouldn't touch it. The other keys are OK, since they start with C-c which is the keycombo modespecific keys are "supposed" to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:51:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:51:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-606250 ] python-mode kills arrow in gdb (gud.el) Message-ID: Bugs item #606250, was opened at 2002-09-08 04:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 >Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode kills arrow in gdb (gud.el) Initial Comment: [ forwarded from http://bugs.debian.org/159628 ] missing proper category ... Once python-mode.el has been loaded, all GDB buffers stop showing the little arrow that lives in the "fringe" on the left side of an emacs21 frame. To be specific, the arrow appears and then disappears right away, each time a 'step' or 'next' command is run. I traced the problem down to the unconditional hooking of 'comint-output-filter-functions, python-mode.el line 3472 to be exact: (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file) I haven't tested it fully, but I've found that if I take this line out, GDB can show its arrow once more. There is code in python-mode.el to insert this hook in a buffer-local fashion only in the '*Python*' buffer.. maybe that should be reviewed and used instead of this global hook? (took forever to figure out it was python-mode causing the problem..) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:51 Message: Logged In: YES user_id=33168 Barry, I thought you worked on this? Perhaps this is a duplicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:52:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:52:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-606254 ] py-electric-colon & delete-selection-mod Message-ID: Bugs item #606254, was opened at 2002-09-08 04:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 >Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: py-electric-colon & delete-selection-mod Initial Comment: python-elisp: py-electric-colon doesn't honour delete-selection mode [forwarded from http://bugs.debian.org/158811] With emacs 21 in delete-selection mode, typing a character when the region is active is supposed to replace the contents of the region. In python-mode, this doesn't work if the colon character is typed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:52:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:52:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-606251 ] elisp: doesn't recognize comment-syntax Message-ID: Bugs item #606251, was opened at 2002-09-08 04:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 >Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: elisp: doesn't recognize comment-syntax Initial Comment: [forwarded from http://bugs.debian.org/159630] It would be awfully nice if python-mode.el knew about python comment syntax and told emacs about it, so that the M-q fill-paragraph command that formats comment blocks so nicely in C and Perl modes would do the right thing. As it stands, M-q in the middle of the comment block on something like this:.. def func(): blah = 2 # this is a comment # this is also a comment foo = 3 jams the entire function into one line, statements and comments and all. I'd really like it to identify the comments, set the region around them, do a normal paragraph-fill (with the fill-prefix set to the existing indentation), then restore the region. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:53:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:53:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-618146 ] overflow error in calendar module Message-ID: Bugs item #618146, was opened at 2002-10-03 12:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 >Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kaleb Pederson (kibab) Assigned to: Nobody/Anonymous (nobody) Summary: overflow error in calendar module Initial Comment: The calendar module doesn't explicitly say that it doesn't work for dates pre-1970. The best case is that this is a DOCUMENTATION BUG. I would prefer to see a more powerful date module that starts at the beginning of the Gregorian calendar. What it does say: >From http://www.python.org/doc/current/lib/module- calendar.html: (when 2.2.1 is current) weekday(year, month, day) - Returns the day of the week (0 is Monday) for year (1970-...), month (1-12), day (1-31). // I figured that was fine, I can avoid using that function in my wrapper timegm(tuple) - An unrelated but handy function that takes a time tuple such as returned by the gmtime() function in the time module, and returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others' inverse. // Okay, I can avoid that too, especially since it is "unrelated" I probably should have got a clue based on the above, but I didn't.... Here is the traceback: (under python 2.2.1-Windows) >>> import calendar >>> calendar.monthcalendar(1969,12) Traceback (most recent call last): File "", line 1, in ? File "c:\progra~1\python22\lib\calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "c:\progra~1\python22\lib\calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "c:\progra~1\python22\lib\calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range The error is identical under Linux There was one related "bug report" previously but nothing else identical: [ 434143 ] calendar module broken for 1900 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:53 Message: Logged In: YES user_id=33168 Is this still a problem in 2.2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:54:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:54:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 10:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 >Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-14 09:15 Message: Logged In: YES user_id=271417 > Date: 2002-10-13 09:02 > Sender: jepler > Logged In: YES > user_id=2772 > > Don't shared modules need the extension .pyd instead of .dll? > No, I am able to load the .dll from the command line version of Python. Also: >>> imp.get_suffixes() [('.pyd', 'rb', 3), ('.dll', 'rb', 3), ('.py', 'r', 1), ('.pyw', 'r', 1), ('.pyc', 'rb', 2)] shows that Python is searching for DLLs. > Is sys.path[0] some absolute directory (the one containing > idle.py, for instance) instead of '.'? > Ahh, that is the true problem. sys.path in Idle is: >>> sys.path ['C:\PROGRA~1\Python22\Tools\idle', 'C:\PROGRA~1\Python22', 'C:\Program Files\Python22\DLLs', 'C:\Program Files\Python22\lib', 'C:\Program Files\Python22\lib\lib-tk', 'C:\Program Files\Python22', 'C:\Program Files \Python22\lib\site-packages'] while sys.path in the command line interpreter is: >>> sys.path ['', 'C:\PROGRA~1\Python22', 'C:\Program Files\Python22\DLLs', 'C:\Program Files\Python22\lib', 'C:\Program Files\Python22\lib\lib-tk', 'C:\Program Files\Python22', 'C:\Program Files\Python22\lib\site-packages'] So the correct title for this bug report should be "Idle replaces sys.path[0] rather than appending a new entry to the list". This means that programs that work when run through the command-line interpreter may break quite dramatically when run from Idle, and vice versa. Leslie ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-10-13 09:02 Message: Logged In: YES user_id=2772 Don't shared modules need the extension .pyd instead of .dll? Is sys.path[0] some absolute directory (the one containing idle.py, for instance) instead of '.'? Is there a way to run idle with -v so that it lists directories and files it tries to import as modules? ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-07 17:53 Message: Logged In: YES user_id=271417 I should have noted that 'import' _does_ work to a degree - 'import os' worked. The '_example.dll' that I am trying to import is the 'shapes' example that is distributed with SWIG 1.3.15, and should import without any trouble. It does import just fine from the command line version of Python, but not from Idle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:49:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:49:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-584409 ] add way to detect bsddb version Message-ID: Bugs item #584409, was opened at 2002-07-21 03:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=584409&group_id=5470 >Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add way to detect bsddb version Initial Comment: The bsddb module docs say that some Python configurations use Berkeley db 1.85 and others use the incompatible 2.0. Maybe by now there are later versions as well. There's no way listed for a Python script to know which version of bsddb is running underneath! That's not so great, since the versions don't interoperate and don't support the same operations. Proposed fix: please add a new function to the module, bsddb.db_version(). This would return a constant string like "1.85" or "2.0", built at Python configuration time. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-25 11:06 Message: Logged In: YES user_id=44345 I can't comment on #504282 (I don't know what the problem is because the poster didn't provide enough information about the files and their names). I attached a patch to #491888 which should solve that problem. still-unconvinced-ly y'rs, Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-25 05:08 Message: Logged In: YES user_id=21627 It would solve bug #491888, and allow to give a better diagnostic for #504282. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-24 14:10 Message: Logged In: YES user_id=44345 What would you have it report? Dbhash is nothing more than a thin wrapper around bsddb. Whichdb is a very fragile beast in my opinion, but it does already do some file content introspection, and if the file is some sort of Berkeley DB hash file, it will report it more-or-less correctly as "dbhash" (more correct in my opinion than returning None or ""). This includes files created using the dbm module, if that module was linked with the dbm emulation API of Berkeley DB. I still fail to see how any of this detection people propose would help. If you have a version 5 hash file it doesn't matter how positive you are about it. A later version of the Berkeley DB library which expects a version 7 hash file is still going to barf on the older file format. To make things work again you're going to have to resort to running Sleepycat's tools to convert the file to the proper format. It's not like you can detect file version differences and then plunge ahead along a different path without alerting the user to the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 13:29 Message: Logged In: YES user_id=21627 No, the main point would be that whichdb would not incorrectly report the file format as 'dbhash', when it isn't (because dbhash supports a different version). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-24 10:54 Message: Logged In: YES user_id=44345 This is precisely what Sleepycat's db_dump/db_load type tools take care of. It's a one-time thing. When you upgrade from one version of Berkeley DB to another you need to run these tools to make sure the file formats are up-to-date. The only problem I see here with the current code is that the exception which is raised is rather mystical - something like a very large number followed by "invalid argument". The most significant change I would see making here is to have the bsddb module recognize that weird error and raise an exception with a saner message. I can't see the programmer or the user getting more information out of "expected hash file format version 7 but got hash file format version 5". ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 09:24 Message: Logged In: YES user_id=12800 We could probably write a little utility to sniff file version numbers based on the magic number as given in this doco: http://www.sleepycat.com/docs/ref/install/magic.txt ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 03:34 Message: Logged In: YES user_id=21627 There is a bug report (somewhere) that whichdb incorrectly determines the DB module. In that case, whichdb would correctly find out that this is a Sleepycat database, and suggest to use dbhash. In turn, dbhash would fail to open the file, because the file version was incorrect. It would have been correct to use the dbm module, since the dbm library was also based on Sleepycat, but had a different version than the bsddb library installed on the same system. This problem can be solved if you can find out what file version(s) your bsddb module supports. The library version seems less useful to me, indeed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-23 22:53 Message: Logged In: YES user_id=12800 It's useful if for no other reason than to figure out which bugs you need to work around . BTW, PyBSDDB does give you the ability to find out both the version of the wrapper you've got and the version of the underlying library.: >>> import bsddb3 >>> bsddb3.__version__ '3.3.0' >>> bsddb3._db.version() (3, 3, 11) You've also got DB_VERSION_STRING, DB_VERSION_MAJOR and DB_VERSION_MINOR. Note that if you're linking against a newer version of the library using the 1.85 API, *that* might be a difficult thing to figure out. Off hand (and I can't check right now), I don't know if that would give yo a different bsddb3._db version constant or would otherwise be detectable. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-23 20:15 Message: Logged In: YES user_id=44345 I agree, if it's wanted badly enough, we can figure out what version was linked with the module code. The "define macros at configure time" idea is possible. The "create a database and peek at it" idea won't work though. There are library version numbers and file versions. They don't always change in sync. Like I said before, I'm skeptical a Python script would really need to know what version of the underlying library was linked with bsddbmodule.o. Can you motivate things with a use case? Skip ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-23 19:35 Message: Logged In: NO How can it be "impossible" to find out? The build script for the bsddb module can check what version is being linked, and include a string reachable from Python. At worst, there could be a routine added to the module that actually creates a database, then examines the db file and figures out from the bytes inside which version it is. Paul ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-23 17:50 Message: Logged In: YES user_id=21627 I also believe that this problem should be fixed by importing pybsddb3. On this issue itself: it turns out impossible to find out, programmatically, what version of Sleepycat DB you are running if all you have is the compatibility API: both the compile-time and the run-time version information is not available. Furthermore, you cannot include both new and old headers, since they conflict. So given the current code base, this problem cannot be solved. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-22 21:18 Message: Logged In: YES user_id=44345 Sorry for the lack of clarity. What I should have said is that the code which implements the bsddb extension module only calls the 1.85-compatible C API exposed when you configure the Berkeley DB code using the --enable-compat185 flag. All the wonders and mysteries of the later parts of the API are lost on the bsddb code. There are two levels of compatibility, the API level and the file format level. All users of the bsddb module should care about is the file format level compatibility and handling that is a one-time problem dealt with using tools provided by Sleepycat as part of their distribution. The topic of including bsddb3 in the standard distribution has been discussed before. For one example, see: http://mail.python.org/pipermail/python-dev/2002-January/019261.html I think the main stumbling block to incorporation is that it only works with versions 3 and 4 of the Berkeley DB library. There is a more recent thread that currently escapes my feeble attempts to find it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2002-07-22 16:26 Message: Logged In: YES user_id=72053 OK, it looks like both the docs and Skip's note are a bit unclear. When you say only the 1.85 API is exposed, does that mean the 1.85 file format is also used either way? In particular, if Python is linked with Berkeley DB 2.0 and I create a db with it, will that db interoperate with another application that's linked to Berkeley DB 1.85? If it won't interoperate, then it's definitely worthwhile to add some kind of call to the Python bsddb module to let Python scripts find out which file format they're dealing with. Also, I didn't realize only the 1.85 API was supported. I hope pybsddb3 can become part of the standard Python distribution, since I'd like to use Sleepycat's transaction features from Python scripts. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-07-22 08:31 Message: Logged In: YES user_id=44345 This is an interesting idea, but one that I think is less useful than you might believe. The bsddb module exposes the same API based on the 1.85 C API regardless what version of Berkeley DB you link with. (I have linked it with versions 1.85 through 4.something.) I've been using the bsddb module since its inclusion in Python and have never actually cared what version of the underlying C API the module what linked with. Someone programming to the C API *would* care about version differences, because the C API has grown richer over the years. The bsddb module code just hasn't ever used any new functionality. Note that the pybsddb3 module does use the new functionality in the version 3 and 4 APIs. What changes on you between versions are the file formats, and you should only care about that at the point where you upgrade from one version of Berkeley DB to another. (Generally, you realize this when you start getting errors trying to open old databases.) Sleepycat provides command line tools to help you convert from one file version to another, so once you realize your file formats have changed, you wind up poking around your disk looking for old format Berkeley DB files, run the tools on them, then go back to more interesting things, like writing stable sorts. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=584409&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:54:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:54:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-621554 ] menues in emacs21 in transient mode Message-ID: Bugs item #621554, was opened at 2002-10-10 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 >Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: menues in emacs21 in transient mode Initial Comment: [from http://bugs.debian.org/160130 and http://bugs.debian.org/144653] python-elisp: Menus don't work under emacs21 in transient mark mode Under Emacs 21, any attempt to access the menus in python-mode fails unless the mark is active, with the message Debugger entered--Lisp error: (mark-inactive) signal(mark-inactive nil) mark() This happens only if transient-mark-mode (menu item: Options->Active Region Highlighting) is active and 'debug-on-error' is on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 From noreply@sourceforge.net Sat Nov 2 02:55:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 18:55:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh Message-ID: Bugs item #626543, was opened at 2002-10-21 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't do HTTP-EQUIV & Refresh Initial Comment: I just added support for HTML's META HTTP-EQUIV and zero-time Refresh HTTP headers to my 'ClientCookie' package (which exports essentially a clone of the urllib2 interface that knows about cookies, making use of urllib2 in the implementation). I didn't make a patch for urllib2 itself but it would be easy to do so. I don't plan to do this immediately, but will eventually (assuming Jeremy thinks it's advisible) -- I just wanted to register this fact to prevent duplication of effort. [BTW, this version of ClientCookie isn't on my web page yet -- my motherboard just died.] I'm sure you know this already, but: HTTP-EQUIV is just a way of putting headers in the HEAD section of an HTML document; Refresh is a Netscape 1.1 header that indicates that a browser should redirect after a specified time. Refresh headers with zero time act like redirections. The net result of the code I just wrote is that if you urlopen a URL that points to an HTML document like this: you're automatically redirected to "http://acme.com/new_url.htm". Same thing happens if the Refresh is in the HTTP headers, because all the HTTP-EQUIV headers are treated like real HTTP headers. Refresh with non-zero delay time is ignored (the urlopen returns the document body unchanged and does not redirect, but does still add the Refresh header to the HTTP headers). A few issues: 0) AFAIK, the Refresh header is not specified in any RFC, but only here: http://wp.netscape.com/assist/net_sites/pushpull.html (HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe earlier ones too) 1) Infinite loops should be detected, as for HTTP 30x? Presumably yes. 2) Should add HTTP-EQUIV headers to response object, or just treat them like headers internally? Perhaps it should be possible to get both behaviours? 3) Bug in my implementation: is greedy with reading body data from httplib's file object. John ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 09:30 Message: Logged In: YES user_id=21627 I would try to subclass HTTPHandler, and then provide a build_opener wrapper that installs this handler instead of the normal http handler (the latter is optional, since the user could just do build_opener(HTTPRefreshHandler)). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-23 19:20 Message: Logged In: YES user_id=261020 What do you think the solution to the backwards- compatibility problem is? Leave urllib2 as-is? Add a switch to turn it on? Something else? At the moment, I just deal with it in AbstractHTTPHandler. It would be nice to treat it like the other redirections, by writing a RefreshHandler -- this would solve the backwards- compatibility issue. However, OpenerDirector.error always calls http_error_xxx ATM (where xxx is the HTTP error code), so without changing that, I don't think a RefreshHandler is really possible. I suppose the sensible solution is just to make a new HTTPHandler and HTTPSHandler? Can you think of any way in which supporting HTTP-EQUIV would mess up backwards compatibility, assuming the body is unchanged but the headers do have the HTTP-EQUIV headers added? John ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 09:54 Message: Logged In: YES user_id=21627 In addition to the issues you have mentioned, there is also the backwards compatibility issue: Some applications might expect to get a meta-refresh document from urllib, then parse it and retry themselves. Those applications would break with such a change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 From noreply@sourceforge.net Sat Nov 2 04:32:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Nov 2002 20:32:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter (?) refct (?) bug Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter (?) refct (?) bug Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sat Nov 2 16:46:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 08:46:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-632628 ] problem w/patch #569139 Message-ID: Bugs item #632628, was opened at 2002-11-02 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632628&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: problem w/patch #569139 Initial Comment: Martin, I believe you checked in this patch which implementated of major, minor and makedev. I tried to mail you about this, but I'm not sure it went through. There seems to be a problem in posix_mknod (Modules/posixmodule.c:5180). There are 3 i's passed to PyArg_ParseTuple(), but I believe there should only be 2 (mode and device). Here's the line: PyArg_ParseTuple(args, "s|iii:mknod", &filename, &mode, &device)) If it's correct to only have 2 i's, assign back to me if you want me to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632628&group_id=5470 From noreply@sourceforge.net Sat Nov 2 17:43:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 09:43:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-632628 ] problem w/patch #569139 Message-ID: Bugs item #632628, was opened at 2002-11-02 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632628&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: problem w/patch #569139 Initial Comment: Martin, I believe you checked in this patch which implementated of major, minor and makedev. I tried to mail you about this, but I'm not sure it went through. There seems to be a problem in posix_mknod (Modules/posixmodule.c:5180). There are 3 i's passed to PyArg_ParseTuple(), but I believe there should only be 2 (mode and device). Here's the line: PyArg_ParseTuple(args, "s|iii:mknod", &filename, &mode, &device)) If it's correct to only have 2 i's, assign back to me if you want me to fix it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-02 18:43 Message: Logged In: YES user_id=21627 Thanks for pointing this out. Fixed in 2.270. (and no, I haven't seen your message, for some reason). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632628&group_id=5470 From noreply@sourceforge.net Sat Nov 2 19:47:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 11:47:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-604128 ] time.struct_time undocumented Message-ID: Bugs item #604128, was opened at 2002-09-03 11:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.struct_time undocumented Initial Comment: The time module has a mystery name called "struct_time" which is undocumented. It is used in a couple of places such as imaplib.py, test_structseq.py and test_strptime.py. It should be documented. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-11-02 11:47 Message: Logged In: YES user_id=357491 If an agreement can be reached on what it should be renamed to (I thought we had agreed on a name already? I, of course, don't have the email to prove this, though), I am willing to help grep Lib/ and generate patches to replace the calls with the new name (and I will even use unified diffs this time! =). Personally, I think TimeStructType is fine, but we must make sure that it won't be mistaken for the forthcoming datetime type. I would wager that the datetime type would have something named DateTimeType if there is going to be a name that might conflict. I am also willing to write the blurb to document this sucker. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 18:57 Message: Logged In: YES user_id=12800 It should also be renamed to be something like TimeStructType. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 From noreply@sourceforge.net Sat Nov 2 20:03:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 12:03:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field Message-ID: Bugs item #626570, was opened at 2002-10-21 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael S. Fischer (otterley) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() always returns 0 in dst field Initial Comment: time.strptime() has always returned 0 in the Daylight Savings Time flag of the returned tuple. This leads to nasty bugs like the "off by an hour" bug revealed below: >>> strftime("%Y %b %d %H %M %S %Z", localtime(int(mktime(strptime("Oct 18 2002 00:00:00", "%b %d %Y %H:%M:%S"))))) '2002 Oct 18 01 00 00 PDT' ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-11-02 12:03 Message: Logged In: YES user_id=357491 I think Neal is right in thinking that changing this might break backwards compatibility. If someone stored timestamps as the tuples directly and then suddenly the new timestamps for something started having a different dst value all the calculations comparing new and old will be off if they use the dst flag. This tends to be a bad thing when changing between dot releases. Besides, if the DST flag is that important it should have been specified in the string passed to strptime(). Otherwise strptime has to just assume there is none (like in 2.2), or guess (like in 2.3). You are basically paying the price for wanting strptime() to infer what you want dst to be. The docs also say that you are at the mercy of the underlying C library and there is a lot of variety for strptime() since it is not a part of ANSI C. In other words, I say this is all a moot point. If accurate timing is that important use UTC timestamps. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-22 15:42 Message: Logged In: YES user_id=33168 I'll have to look at this more. With 2.3, I get 00 00 00, with 1.5.2, 2.1.1, and 2.2.2, I get 01 00 00. The difference seems to be that the tm_isdst flag is set to -1 (mktime should guess) in 2.3, but the flag is set to 0 in other versions. It's possible this bug may not be able to be fixed due to backwards compatibility. ---------------------------------------------------------------------- Comment By: Michael S. Fischer (otterley) Date: 2002-10-21 16:43 Message: Logged In: YES user_id=7820 I've seen it in 1.5.2, 2.1.3, 2.2 and 2.2.1. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-21 16:34 Message: Logged In: YES user_id=33168 Michael, what version(s) of Python does this effect? 2.2.2? 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 From noreply@sourceforge.net Sat Nov 2 20:07:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 12:07:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 04:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Sat Nov 2 20:53:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 12:53:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Sat Nov 2 20:59:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 12:59:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-551504 ] python -v sometimes fails to find init Message-ID: Bugs item #551504, was opened at 2002-05-02 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=551504&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Joseph Winston (josephwinston) >Assigned to: Neal Norwitz (nnorwitz) Summary: python -v sometimes fails to find init Initial Comment: On HP-UX 11 python -v sometimes fails to find the init method for a dynamic library. An instance of this can be found when trying to load libsip. A possible work around is the following patch: diff -c -c -r1.1 dynload_hpux.c *** dynload_hpux.c 2 May 2002 16:04:08 -0000 1.1 --- dynload_hpux.c 2 May 2002 17:12:01 -0000 *************** *** 29,35 **** flags = BIND_FIRST | BIND_DEFERRED; if (Py_VerboseFlag) { ! flags = DYNAMIC_PATH | BIND_FIRST | BIND_IMMEDIATE | BIND_NONFATAL | BIND_VERBOSE; printf("shl_load %s\n",pathname); } --- 29,35 ---- flags = BIND_FIRST | BIND_DEFERRED; if (Py_VerboseFlag) { ! flags = BIND_FIRST | BIND_IMMEDIATE | BIND_NONFATAL | BIND_VERBOSE; printf("shl_load %s\n",pathname); } I do not know why DYNAMIC_PATH is causing the loading to fail since the man page for shl_load says: DYNAMIC_PATH Allow the loader todynamically search for the library specified by the path argument. The directories to be searched are determined by the +s and +b options of the ld command used when the program was linked. On PA64, this is enabled by default if ld +compat was not specified. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:59 Message: Logged In: YES user_id=33168 Seems to make sense. Since I am testing on HP-UX now, I fixed this. I did not backport to 2.2.3. Not sure how much of a problem this is. If it's a big problem, I suppose it could be backported. It seems like it could change behaviour. Checked in as: Python/dynload_hpux.c 2.8 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:25 Message: Logged In: YES user_id=6380 The origin for this code is lost in history. I propose to accept this patch, since it's strange that in verbose mode the dynamic library search semantics should be any different than normally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=551504&group_id=5470 From noreply@sourceforge.net Sat Nov 2 21:05:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 13:05:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-618146 ] overflow error in calendar module Message-ID: Bugs item #618146, was opened at 2002-10-03 12:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 >Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kaleb Pederson (kibab) Assigned to: Nobody/Anonymous (nobody) Summary: overflow error in calendar module Initial Comment: The calendar module doesn't explicitly say that it doesn't work for dates pre-1970. The best case is that this is a DOCUMENTATION BUG. I would prefer to see a more powerful date module that starts at the beginning of the Gregorian calendar. What it does say: >From http://www.python.org/doc/current/lib/module- calendar.html: (when 2.2.1 is current) weekday(year, month, day) - Returns the day of the week (0 is Monday) for year (1970-...), month (1-12), day (1-31). // I figured that was fine, I can avoid using that function in my wrapper timegm(tuple) - An unrelated but handy function that takes a time tuple such as returned by the gmtime() function in the time module, and returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others' inverse. // Okay, I can avoid that too, especially since it is "unrelated" I probably should have got a clue based on the above, but I didn't.... Here is the traceback: (under python 2.2.1-Windows) >>> import calendar >>> calendar.monthcalendar(1969,12) Traceback (most recent call last): File "", line 1, in ? File "c:\progra~1\python22\lib\calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "c:\progra~1\python22\lib\calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "c:\progra~1\python22\lib\calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range The error is identical under Linux There was one related "bug report" previously but nothing else identical: [ 434143 ] calendar module broken for 1900 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:05 Message: Logged In: YES user_id=33168 I can't replicate on Linux w/2.2.2 or 2.3, changing category to Windows. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:53 Message: Logged In: YES user_id=33168 Is this still a problem in 2.2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 From noreply@sourceforge.net Sat Nov 2 21:07:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 13:07:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-602259 ] 3rd parameter for Tkinter.scan_dragto Message-ID: Bugs item #602259, was opened at 2002-08-30 03:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602259&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Neal Norwitz (nnorwitz) Summary: 3rd parameter for Tkinter.scan_dragto Initial Comment: In Tk8.3 (possibly earlier), one can add a third optional parameter, called "gain", which determines the multiplier used when performing the panning operation. The Tkinter call does not allow this parameter to be passed in the resultant Tk's default gain of 10 is often unusable. Work around is to just do this call manually: self.canv.tk.call(self.canv._w, 'scan', 'dragto', event.x, event.y, 1) uses a gain of `1'. [from http://bugs.debian.org/158168] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602259&group_id=5470 From noreply@sourceforge.net Sat Nov 2 21:10:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 13:10:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-592161 ] installation errors Message-ID: Bugs item #592161, was opened at 2002-08-07 12:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470 Category: Distutils Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Alicia C. Hopkins (aliciahopkins) Assigned to: Nobody/Anonymous (nobody) Summary: installation errors Initial Comment: with the use of python2 setup.py install, I get the following errors File "setup.py", line 30, in ? packages = ['distutils', 'distutils.command'], File "distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "distutils/dist.py", line 130, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' HELP! Alicia Hopkins ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:10 Message: Logged In: YES user_id=33168 Do you still have this problem with Distutils-1.0.3? That is the version in Python 2.2.2. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-08 11:02 Message: Logged In: NO The setup.py is in the main directory Distutils-1.0.2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-08 04:45 Message: Logged In: YES user_id=6656 Which setup.py is that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592161&group_id=5470 From noreply@sourceforge.net Sat Nov 2 21:14:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 13:14:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 14:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:14 Message: Logged In: YES user_id=33168 Jason, still with us? What version of python were you having the problem with? 2.1.x? 2.2.x? Do you have the problem with 2.2? Have you looked at patch #604210 (http://python.org/604210)? Can you test that? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-06 20:20 Message: Logged In: YES user_id=85984 Still having the problem, but I'm unsure how to proceed. nslookup and host both return instantly when querying datavortex.net. Only Python seems to exhibit this problem, but it still could be a system misconfiguration. This is the only time I've ever seen/heard of this behavior. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 18:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 15:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 17:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 17:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 12:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 17:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 17:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply@sourceforge.net Sat Nov 2 21:32:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 13:32:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC Message-ID: Bugs item #454030, was opened at 2001-08-21 19:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: distutils cannot link C++ code with GCC Initial Comment: It is mandatory to link C++ code against -lstdc++ -lm when creating an extension. distutils does not do this in 2.1.1 Here is a setup.py for Python CXX that works around the problem, but it would be better for distutils to understand enough about C++ to do the right thing. THen the code for other compilers could be added. But GCC is important enough to do first. You can get the CXX sources from http://sourceforge.net/projects/cxx/ from distutils.core import setup, Extension if os.name == 'posix': CXX_libraries = ['stdc++','m'] else: CXX_libraries = [] setup(name="pycxx_demo", version="1.0", ext_modules= [Extension( "example", sources = [ "Demo/example.cxx", "Demo/python.cxx", "Demo/range.cxx", "Demo/rangetest.cxx", "Src/cxx_extensions.cxx", "Src/cxxextensions.c", "Src/cxxsupport.cxx", "Src/IndirectPythonInterface.cxx" ], include_dirs = [ ".", "Demo" ], libraries = CXX_libraries ) ] ) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:32 Message: Logged In: YES user_id=33168 Barry, is this still a problem w/2.2.2? ---------------------------------------------------------------------- Comment By: Barry Alan Scott (barry-scott) Date: 2002-01-27 06:42 Message: Logged In: YES user_id=28665 Yes using G++ is another way to solve this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 05:08 Message: Logged In: YES user_id=6656 Is this the same problem as [ #413582 ] g++ must be called for c++ extensions ? Not a rhetorical question, I would like to know! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 16:50 Message: Logged In: YES user_id=6380 Nobody at PL understands distutils well enough to do this, so lowering the priority -- there's no way this will hold up the release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 From noreply@sourceforge.net Sat Nov 2 22:04:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 14:04:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-618146 ] overflow error in calendar module Message-ID: Bugs item #618146, was opened at 2002-10-03 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kaleb Pederson (kibab) Assigned to: Nobody/Anonymous (nobody) Summary: overflow error in calendar module Initial Comment: The calendar module doesn't explicitly say that it doesn't work for dates pre-1970. The best case is that this is a DOCUMENTATION BUG. I would prefer to see a more powerful date module that starts at the beginning of the Gregorian calendar. What it does say: >From http://www.python.org/doc/current/lib/module- calendar.html: (when 2.2.1 is current) weekday(year, month, day) - Returns the day of the week (0 is Monday) for year (1970-...), month (1-12), day (1-31). // I figured that was fine, I can avoid using that function in my wrapper timegm(tuple) - An unrelated but handy function that takes a time tuple such as returned by the gmtime() function in the time module, and returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others' inverse. // Okay, I can avoid that too, especially since it is "unrelated" I probably should have got a clue based on the above, but I didn't.... Here is the traceback: (under python 2.2.1-Windows) >>> import calendar >>> calendar.monthcalendar(1969,12) Traceback (most recent call last): File "", line 1, in ? File "c:\progra~1\python22\lib\calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "c:\progra~1\python22\lib\calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "c:\progra~1\python22\lib\calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range The error is identical under Linux There was one related "bug report" previously but nothing else identical: [ 434143 ] calendar module broken for 1900 ---------------------------------------------------------------------- >Comment By: Kaleb Pederson (kibab) Date: 2002-11-02 22:04 Message: Logged In: YES user_id=157918 I checked it out under Linux on 2.2.2 and this is what I found. >>> calendar.monthcalendar(1902,01) [[0, 0, 1, 2, 3, 4, 5], [6, 7, 8, 9, 10, 11, 12], [13, 14, 15, 16, 17, 18, 19], [20, 21, 22, 23, 24, 25, 26], [27, 28, 29, 30, 31, 0, 0]] >>> calendar.monthcalendar(1901,12) Traceback (most recent call last): File "", line 1, in ? File "calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range >>> calendar.monthcalendar(2038,1) [[0, 0, 0, 0, 1, 2, 3], [4, 5, 6, 7, 8, 9, 10], [11, 12, 13, 14, 15, 16, 17], [18, 19, 20, 21, 22, 23, 24], [25, 26, 27, 28, 29, 30, 31]] >>> calendar.monthcalendar(2038,2) Traceback (most recent call last): File "", line 1, in ? File "calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I consider this much better than before. I would only recommend that the upper and lower bounds for valid limits be added to the documentation as it isn't stated anywhere in the docs. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:05 Message: Logged In: YES user_id=33168 I can't replicate on Linux w/2.2.2 or 2.3, changing category to Windows. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 02:53 Message: Logged In: YES user_id=33168 Is this still a problem in 2.2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 From noreply@sourceforge.net Sun Nov 3 00:02:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 16:02:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Sun Nov 3 00:16:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 16:16:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-618146 ] overflow error in calendar module Message-ID: Bugs item #618146, was opened at 2002-10-03 12:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 Category: Windows Group: Python 2.2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Kaleb Pederson (kibab) >Assigned to: Neal Norwitz (nnorwitz) Summary: overflow error in calendar module Initial Comment: The calendar module doesn't explicitly say that it doesn't work for dates pre-1970. The best case is that this is a DOCUMENTATION BUG. I would prefer to see a more powerful date module that starts at the beginning of the Gregorian calendar. What it does say: >From http://www.python.org/doc/current/lib/module- calendar.html: (when 2.2.1 is current) weekday(year, month, day) - Returns the day of the week (0 is Monday) for year (1970-...), month (1-12), day (1-31). // I figured that was fine, I can avoid using that function in my wrapper timegm(tuple) - An unrelated but handy function that takes a time tuple such as returned by the gmtime() function in the time module, and returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others' inverse. // Okay, I can avoid that too, especially since it is "unrelated" I probably should have got a clue based on the above, but I didn't.... Here is the traceback: (under python 2.2.1-Windows) >>> import calendar >>> calendar.monthcalendar(1969,12) Traceback (most recent call last): File "", line 1, in ? File "c:\progra~1\python22\lib\calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "c:\progra~1\python22\lib\calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "c:\progra~1\python22\lib\calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range The error is identical under Linux There was one related "bug report" previously but nothing else identical: [ 434143 ] calendar module broken for 1900 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 19:16 Message: Logged In: YES user_id=33168 Checked in as: Doc/lib/libcalendar.tex 1.16 and 1.14.6.2 ---------------------------------------------------------------------- Comment By: Kaleb Pederson (kibab) Date: 2002-11-02 17:04 Message: Logged In: YES user_id=157918 I checked it out under Linux on 2.2.2 and this is what I found. >>> calendar.monthcalendar(1902,01) [[0, 0, 1, 2, 3, 4, 5], [6, 7, 8, 9, 10, 11, 12], [13, 14, 15, 16, 17, 18, 19], [20, 21, 22, 23, 24, 25, 26], [27, 28, 29, 30, 31, 0, 0]] >>> calendar.monthcalendar(1901,12) Traceback (most recent call last): File "", line 1, in ? File "calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range >>> calendar.monthcalendar(2038,1) [[0, 0, 0, 0, 1, 2, 3], [4, 5, 6, 7, 8, 9, 10], [11, 12, 13, 14, 15, 16, 17], [18, 19, 20, 21, 22, 23, 24], [25, 26, 27, 28, 29, 30, 31]] >>> calendar.monthcalendar(2038,2) Traceback (most recent call last): File "", line 1, in ? File "calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I consider this much better than before. I would only recommend that the upper and lower bounds for valid limits be added to the documentation as it isn't stated anywhere in the docs. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 16:05 Message: Logged In: YES user_id=33168 I can't replicate on Linux w/2.2.2 or 2.3, changing category to Windows. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 21:53 Message: Logged In: YES user_id=33168 Is this still a problem in 2.2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 From noreply@sourceforge.net Sun Nov 3 00:38:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 16:38:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-631066 ] running regrtest in user mode fails Message-ID: Bugs item #631066, was opened at 2002-10-30 09:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631066&group_id=5470 Category: Installation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel T. (daniel_t) >Assigned to: Neal Norwitz (nnorwitz) Summary: running regrtest in user mode fails Initial Comment: Running on MacOS X 10.1.5 Installed Python 2.2.2 from an admin account into a folder that only admins can modify. Ran regrtest from a user account. Some 26 tests fail with the following error: test test_builtin crashed -- exceptions.IOError: [Errno 13] Permission denied: '@test' Comment from Jack Jansen: The bug is with Python's test suite. The test suite expects to have write permission in Python's Lib/test directory (or somewhere thereabouts). The bug isn't mac-specific, but it's triggered by person A doing the install and person B running the test set. At the very least the test set should detect this situation and print a warning that you may experience random failures that do not point to problems with the python installation, I guess... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 19:38 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_support.py; 1.44 and 1.40.8.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631066&group_id=5470 From noreply@sourceforge.net Sun Nov 3 02:28:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 18:28:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-475951 ] HP-UX: Problem building socket Message-ID: Bugs item #475951, was opened at 2001-10-29 05:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=475951&group_id=5470 Category: Build Group: Platform-specific >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Neal Norwitz (nnorwitz) Summary: HP-UX: Problem building socket Initial Comment: On HP-UX 11, I get errors compiling Python 2.1.1 from source. It crashes when parsing sys/socket.h Here's the offending code: extern sbsize_t sendfile __((int, int, off_t, bsize_t, const struct iovec *, int)); extern sbsize_t sendpath __((int, char *, off_t, bsize_t, const struct iovec *, int)); When I switch from gcc to cc (native c compiler) the socket library compiles, but many other libs don't. (sidenote: when using cc, cc is noteably faster than gcc) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:28 Message: Logged In: YES user_id=33168 Since 2.2.2 and 2.3 both build (and test successfully) on HP-UX 11, I'm closing this bug. Carl, if you still have a problem re-open this bug report or open a new one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-12 03:51 Message: Logged In: NO 'sbsize_t' is an HPUX11i issue - possible solution see below. I can't test it, I have only 11 without 'i'. More important is the fact, that Python uses UNIX style sockets as far as i understand. HPUX offers two types of sockets: BSD-style via libc and UNIX style via libxnet. The HPUX11 python build is linked against libxti (not xnet) via libnsl. Compilation of socketmodule.c HAS TO BE DONE with _XOPEN_SOURCE_EXTENDED defined - see below. With this one gets rid of a lot of compiler warnings with socketmodule.c However, my poor C skills don't tell me if -lxnet should be added additionally at link time or not. Carl cmkleffner.gmx.de -------------- The following article on devresource is a must for all HPUX porters: http://devresource.hp.com/STKL/inhibitors.html 'Linux porting inhibitors' > socket flavors > > HP-UX supports two types of sockets - BSD 4.2 style sockets in libc and UNIX95/98 > style sockets in libxnet. Linux's socket is a UNIX98 style socket, so the path of least > resistance would be to use the UNIX95/98 style socket in HP-UX. However, since > socklen_t in Linux is typedef to int while socklen_t in HP-UX is typedef to size_t, some > additional reconciliation may still be needed. Note, socklen_t is used in places where > "len" objects are defined. An example of its use is shown below. > > To use UNIX95/98 style sockets in HP-UX, the libxnet library needs to be added to the > link line. Also, the macro, _XOPEN_SOURCE, needs to be defined, and the macro, > _XOPEN_SOURCE_EXTENDED, needs to be defined as 1. Refer to HP-UX manpage, > xopen_networking(7) for further details. http://gcc.gnu.org/ml/gcc-prs/2001-07/msg00527.html . . . . . > HPUX 11i is quite different from HPUX 11 because many of the > header files have been changed and new types are used such as > sbsize_t and bsize_t. http://gcc.gnu.org/ml/gcc-bugs/2001-09/msg00139.html > To: hpux at connect dot org dot uk, gcc-bugs at gcc dot gnu dot org > Subject: GCC 3.0.1 on HP-UX 11i > From: Remi COLLET > Date: Wed, 05 Sep 2001 17:40:33 +0200 > Organization: IUT de Reims - Departement Informatique > . . . . . > 3) non ANSI declaration of sendfile and sendpath (C++) in socket.h > > Copy socket.h in > /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.0.1/include/sys > > Replace (line 470) > > > inline sbsize_t sendfile(a,b,c,d,e,f) int a,b,f; off_t c; bsize_t d; const struct iovec * e; { return __sendfile64(a,b,c,d,e,f); } > > inline sbsize_t sendpath(a,b,c,d,e,f) int a,f; char *b; off_t c; bsize_t d; const struct iovec * e; { return __sendpath64(a,b,c,d,e,f); } > > > > > With: > > > inline sbsize_t sendfile(int a,int b,off_t c,bsize_t d,const struct iovec *e,int f) > > { return __sendfile64(a,b,c,d,e,f); } > > inline sbsize_t sendpath(int a,char *b,off_t c,bsize_t d,const struct iovec *e,int f) > > { return __sendpath64(a,b,c,d,e,f); } > > > > > Then, all works fine ! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-06 14:12 Message: Logged In: YES user_id=21627 The likely cause is that sbsize_t is not defined. Please try to find out what header file of HP-UX defines sbsize_t, and under what conditions? Outright including that header file probably is the wrong solution, so please also find out where it is included from, tracking it eventually back to socket.h. It appears that a certain #define is missing to cause a proper definition of sbsize_t. We must find out what that define is, and why it is not set when compiling with gcc. Also, could you please identify yourself? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-06 07:42 Message: Logged In: NO gcc --version is now 3.0.1 The problem however is still there: building '_socket' extension gcc -g -O2 -Wall -Wstrict-prototypes -fpic -I. -I/utmnt/ut/si/dv0216/Python-2.1.1/./Include -I/usr/local/include -IInclude/ -c /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c -o build/temp.hp-ux-B.11.11-9000/785-2.1/socketmodule.o In file included from /usr/include/netdb.h:72, from /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:145: /usr/include/sys/socket.h:439: parse error before "sendfile" /usr/include/sys/socket.h:439: parse error before "bsize_t" /usr/include/sys/socket.h:441: parse error before "sendpath" /usr/include/sys/socket.h:441: parse error before "bsize_t" /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c: In function `PySocketSock_accept': /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:795: warning: passing arg 3 of `accept' from incompatible pointer type /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c: In function `PySocketSock_getsockopt': /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:978: warning: passing arg 5 of `getsockopt' from incompatible pointer type /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:992: warning: passing arg 5 of `getsockopt' from incompatible pointer type /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c: In function `PySocketSock_getsockname': /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:1188: warning: passing arg 3 of `getsockname' from incompatible pointer type /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c: In function `PySocketSock_getpeername': /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:1218: warning: passing arg 3 of `getpeername' from incompatible pointer type /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c: In function `PySocketSock_recvfrom': /utmnt/ut/si/dv0216/Python-2.1.1/Modules/socketmodule.c:1376: warning: passing arg 6 of `recvfrom' from incompatible pointer type WARNING: building of extension "_socket" failed: command 'gcc' failed with exit status 1 Here are the offending lines from socket.h extern sbsize_t sendfile __((int, int, off_t, bsize_t, const struct iovec *, int)); extern sbsize_t sendpath __((int, char *, off_t, bsize_t, const struct iovec *, int)); However, my medium c skills tell me that the lines are ok. I cannot offer an explanation why gcc fails here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-01 11:57 Message: Logged In: YES user_id=21627 gcc 2.95 does not support HP-UX 11; this appears to be an instance of that problem. The __va__list problem is not at all Python-specific; it occurs in many packages (just search Google for "HP-UX __va__list"). With such problems, there is no point into looking further into the problem; just drop the compiler. If you want to port Python to HP-UX and gcc 2.95, you are on your own. Notice that gcc 3.0.1 *does* support HP-UX 11; I recommend to upgrade. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-01 10:41 Message: Logged In: NO gcc version is 2.95.3 HP-UX hp18 B.11.11 U 9000/785 2011589119 both Python 2.1.1 and 2.2b1 do not compile ootb here. Error messages during compile are building '_socket' extension gcc -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/utmnt/ut/si/dv0216/Python-2.2b1/./Include -I/usr/local/include -IInclude/ -c /utmnt/ut/si/dv0216/Python-2.2b1/Modules/socketmodule.c -o build/temp.hp-ux-B.11.11-9000/785-2.2/socketmodule.o In file included from /utmnt/ut/si/dv0216/Python-2.2b1/Include/Python.h:42, from /utmnt/ut/si/dv0216/Python-2.2b1/Modules/socketmodule.c:77: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: `__va__list' redefined /usr/include/sys/stdsyms.h:422: warning: this is the location of the previous definition In file included from /utmnt/ut/si/dv0216/Python-2.2b1/Include/Python.h:47, from /utmnt/ut/si/dv0216/Python-2.2b1/Modules/socketmodule.c:77: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: this is the location of the previous definition In file included from /usr/include/netdb.h:72, from /utmnt/ut/si/dv0216/Python-2.2b1/Modules/socketmodule.c:152: /usr/include/sys/socket.h:439: parse error before `sendfile' /usr/include/sys/socket.h:439: parse error before `bsize_t' /usr/include/sys/socket.h:440: warning: data definition has no type or storage class /usr/include/sys/socket.h:441: parse error before `sendpath' /usr/include/sys/socket.h:441: parse error before `bsize_t' /usr/include/sys/socket.h:442: warning: data definition has no type or storage class /usr/include/sys/socket.h:456: parse error before `__sendfile64' /usr/include/sys/socket.h:456: parse error before `bsize_t' /usr/include/sys/socket.h:456: warning: data definition has no type or storage class /usr/include/sys/socket.h:457: parse error before `__sendpath64' /usr/include/sys/socket.h:457: parse error before `bsize_t' /usr/include/sys/socket.h:457: warning: data definition has no type or storage class /usr/include/sys/socket.h:459: parse error before `sendfile' /usr/include/sys/socket.h:459: warning: function declaration isn't a prototype /usr/include/sys/socket.h: In function `sendfile': /usr/include/sys/socket.h:459: parse error before `bsize_t' /usr/include/sys/socket.h: At top level: /usr/include/sys/socket.h:460: parse error before `sendpath' /usr/include/sys/socket.h:460: warning: function declaration isn't a prototype /usr/include/sys/socket.h: In function `sendpath': /usr/include/sys/socket.h:460: parse error before `bsize_t' In file included from /utmnt/ut/si/dv0216/Python-2.2b1/Modules/socketmodule.c:238: /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c: At top level: /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c:203: warning: function declaration isn't a prototype /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c:212: warning: function declaration isn't a prototype /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c: In function `freeaddrinfo': /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c:219: warning: implicit declaration of function `free' /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c: In function `str_isnumber': /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c:231: warning: subscript has type `char' /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c: In function `getaddrinfo': /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c:345: warning: implicit declaration of function `atoi' /utmnt/ut/si/dv0216/Python-2.2b1/Modules/getaddrinfo.c:396: warning: implicit declaration of function `malloc' WARNING: building of extension "_socket" failed: command 'gcc' failed with exit status 1 I now thought that since the errors happen in a system header that compiles with cc and not gcc, why not copy to "socket.h" and delete the two offending lines. However, as you see, is still included (why ?). Another option is using cc just for this library, but I'm not sure, that the object files are compatible. Using cc alone creates a lot of non-working modules, although it is in (extended) ANSI mode. I also tried the HP Porting centre (http://hpux.asknet.de) but the Python 2.1 package there -just like mine- does crash on importing socket (too with 2.2b1) hp18: Python-2.2b1 % ./python Python 2.2b1 (#4, Nov 1 2001, 16:36:54) [C] on hp-uxB Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "", line 1, in ? File "/utmnt/ut/si/dv0216/Python-2.2b1/Lib/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-30 03:56 Message: Logged In: YES user_id=21627 It would be helpful if you would provide all details in a report also. When you say "it crashes", did you really mean "it crashes" (i.e. with a core dump, machine reboot, or the like)? If the compiler merely rejected the code, it would be good to see what the error message was. Please also report version numbers: HP-UX version, gcc version, etc. Are you sure you are using a gcc built for your OS version? If the gcc doesn't get prototypes right, this often comes from having fixincluded header files of a different OS version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-29 07:59 Message: Logged In: YES user_id=6380 Please try again with Python 2.2b1 (http://python.org/2.2/). We've done a lot of work and we've got at least one report that it now works out of the box on HP-UX 11. I'd like to hear if that solves your problems (and if 2.2b1 builds with either compiler). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=475951&group_id=5470 From noreply@sourceforge.net Sun Nov 3 02:31:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 18:31:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-484715 ] Upgrade TCL for windows installer Message-ID: Bugs item #484715, was opened at 2001-11-22 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484715&group_id=5470 >Category: Windows Group: Feature Request Status: Open Resolution: Postponed Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) >Assigned to: Tim Peters (tim_one) Summary: Upgrade TCL for windows installer Initial Comment: Windows installer comes with TCL/TK 8.3.2. The latest version of TCL/TK is 8.3.4. One of the "greatest" features of the latest TCL/TK is the ability to change window icons. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:31 Message: Logged In: YES user_id=33168 Tim, what version of Tcl/Tk is used on Windows now? Can this be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 15:49 Message: Logged In: YES user_id=31435 This isn't "a bug", but it might be a feature request. Alas, I can't make time to do anything about it, and it's too late for 2.2 regardless. Setting to Postponed until after 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484715&group_id=5470 From noreply@sourceforge.net Sun Nov 3 02:36:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 18:36:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-486360 ] Support for page & shortcut icons Message-ID: Bugs item #486360, was opened at 2001-11-28 00:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=486360&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Support for page & shortcut icons Initial Comment: The generated Python documentation should include support for "page" and "shortcut" icons. These are supported (at least) by MSIE and Mozilla 0.9.6 ("page" only for now, but "shortcut" expected for 0.9.7). Netscape 6.x will acquire support from the Mozilla project. More information: http://www.mozilla.org/releases/mozilla0.9.6/ http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:36 Message: Logged In: YES user_id=33168 Fred, did you just check in this change? Should this be closed? http://mail.python.org/pipermail/python-checkins/2002-October/030437.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=486360&group_id=5470 From noreply@sourceforge.net Sun Nov 3 02:57:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 18:57:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-518775 ] buffer object API description truncated Message-ID: Bugs item #518775, was opened at 2002-02-17 10:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518775&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Neal Norwitz (nnorwitz) Summary: buffer object API description truncated Initial Comment: In section 10.6 of the C API reference manual, Python-2-2/Doc/html/api/buffer-structs.html the description for the last subroutine listed, int (*getcharbufferproc) (PyObject *self, int segment, const char **ptrptr) is omitted. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:57 Message: Logged In: YES user_id=33168 Checked in as: Doc/api/newtypes.tex 1.17 and 1.3.6.1 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-03-15 01:16 Message: Logged In: YES user_id=3066 It hasn't been dropped, it just hasn't been written. ;-( There is a general level of incompleteness in the API document which we are aware of and are working to correct (albiet more slowly than we'd like). Assigning to Greg since he spent more time developing the buffer API than anyone else. The documentation for this should be added to the release21-maint and release22-maint branches and the development trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518775&group_id=5470 From noreply@sourceforge.net Sun Nov 3 03:21:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 19:21:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash Message-ID: Bugs item #529750, was opened at 2002-03-13 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 Category: Python Interpreter Core >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Adam M. Fass (afass) >Assigned to: Neil Schemenauer (nascheme) Summary: Circular reference makes Py_Init crash Initial Comment: Call Py_Initialize(), create two objects that reference each other, then call Py_Finalize() and then Py_Intialize() again. This crashes Python with the following error message: Fatal Python error: UNREF invalid object The documentation on Py_Finalize() mentions that circular references will cause memory leaks, but it does not mention this behavior. Platform info: * Windows XP * Visual C++ 6.0 * Python 2.2 ------------------------------ #include "Python.h" int main(int argc, char* argv[]) { char *code1 = "class TestClass:\n\ti = 3\nt1 = TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = t1"; Py_Initialize(); PyRun_SimpleString(code1); Py_Finalize(); Py_Initialize(); Py_Finalize(); } ------------------------------ The string "code1" contains this python code: class TestClass: i = 3 t1 = TestClass() t2 = TestClass() t1.t = t2 t2.t = t1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 22:21 Message: Logged In: YES user_id=33168 I just tested w/a debug build in 2.3 and it crashed on me. It's probably a problem in 2.2.2. Neil, could you try to look at this? I removed the second Py_Finalize() and it still crashed. (gdb) p *op $4 = {_ob_next = 0x4020a7b4, _ob_prev = 0x8124418, ob_refcnt = 0, ob_type = 0x8121140} Note: ob_refcnt == 0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 20:51 Message: Logged In: YES user_id=33168 I just tried the sample code on 2.3.0 and 2.2.1+ on Linux. This didn't crash or misbehave at all. Did you compile python or did you get a binary distribution? Could there be an incompatibility? Can you otherwise use python w/o problems? Could it be specific to your box or windows in general? Can you build python -with-pydebug? Can you test with the python versions in CVS 2.2.1+ or 2.3? ---------------------------------------------------------------------- Comment By: Adam M. Fass (afass) Date: 2002-09-10 14:32 Message: Logged In: YES user_id=485533 I just tried my code with 2.2.1 and got the same exact result. My platform is still the same: Windows XP and Visual C++ 6.0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:54 Message: Logged In: YES user_id=33168 Adam, do you still have this problem, with 2.2.1+? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 13:44 Message: Logged In: YES user_id=35752 I can't reproduce this on Linux with the latest CVS code. I tried with and without Py_DEBUG defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 From noreply@sourceforge.net Sun Nov 3 03:23:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 19:23:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails Message-ID: Bugs item #543244, was opened at 2002-04-12 18:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Jason Tishler (jlt63) Summary: installation atop 2.2 fails Initial Comment: Installing Python 2.2.1 atop Python 2.2 on cygwin fails at the last stage when it tries to create a link from /usr/bin/python.exe -> /usr/bin/python- 2.2.exe. Since the link already exists, installation stops. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 22:23 Message: Logged In: YES user_id=33168 David, Jason, is this still a problem? Can this be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-15 17:22 Message: Logged In: YES user_id=21627 The ln I quoted was actually from a Linux 'make install'; I cannot reproduce the cygwin install since I don't have cygwin - but it *should* only differ in the BINDIR. Since there is only one ln invocation in the makefile, it is hard to believe that 'make install' tries to create a link in the reverse direction. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-04-14 20:31 Message: Logged In: YES user_id=52572 No, it's not that ln. Read my report again. It's linking /usr/bin/python -> /usr/bin/python2.2.exe. No "local" in the path. Since I've already installed 2.2.1, I can't reproduce the behavior anymore without building myself a fresh 2.2... but it happened twice, once on a pydebug installation of 2.2.1 over 2.2 and once on a regular build. -Dave ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 19:13 Message: Logged In: YES user_id=21627 Can you report the precise sequence of commands being executed? Normally, it should be if test -f /usr/local/bin/python; \ then rm -f /usr/local/bin/python; \ else true; \ fi (cd /usr/local/bin; ln python2.2 python) If this is the ln that fails, it is not clear why the target already exists: the rm command is supposed to delete it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-12 19:09 Message: Logged In: YES user_id=31435 Change Group to Platform-specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470 From noreply@sourceforge.net Sun Nov 3 03:28:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 19:28:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky Message-ID: Bugs item #549038, was opened at 2002-04-26 08:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Ka-Ping Yee (ping) Summary: cgitb variable dumps a little flaky Initial Comment: First off, easy problem: lookup() should look in frame.f_globals["__builtins__"] also. Along the same lines, I am not sure if lookup works properly with nested scopes, but since I don't use nested scopes in any of my code this is not a problem for me ;-) Secondly, the parsing in scanvars() is somewhat hacky. For example, given the following line: foo(open(filename).read()) it will think the following variables exist: foo open filename ).read Obviously this last one is incorrect. I am not sure if this is easy to fix or not. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 22:28 Message: Logged In: YES user_id=33168 Jon, is this fixed? Can it be closed? If not, what do you think needs to be done? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-06-26 06:28 Message: Logged In: YES user_id=76089 I'm not quite sure why you were unable to reproduce the ").read" bit. Try the following code: import cgitb; cgitb.enable() filename = "foo" foo(open(filename).read()) The output includes: foo undefined, open undefined, filename = 'foo', ).read undefined Do you get something different? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-06-26 03:11 Message: Logged In: YES user_id=45338 The lookup function looks in frame.f_locals, which does the right thing with respect to nested scopes as far as i can tell. I tested the parser and wasn't able to reproduce the problem you described. Thanks for the bug report. I have committed a change that adds the lookup in __builtins__. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:50 Message: Logged In: YES user_id=6380 Nobody except Ka-Ping Ping understands the code in cgitb.py, so I suggest that you track him down and get him to look at this bug report. In the past I've performed this service myself but I'm getting tired of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470 From noreply@sourceforge.net Sun Nov 3 03:29:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 19:29:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-554676 ] unknown locale de_DE@euro on Suse 8.0 Linux Message-ID: Bugs item #554676, was opened at 2002-05-10 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent wehren (vinweh) >Assigned to: Martin v. Löwis (loewis) Summary: unknown locale de_DE@euro on Suse 8.0 Linux Initial Comment: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 When calling the locale module's getdefaultlocale() method on SuSe 8.0 Linux you get: >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/locale.py", line 337, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.2/locale.py", line 271, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: de_DE@euro Evidently, Python2.2's locale module is unaware of the "somelang_SOMELANG@euro" nomenclature for euro-enabled locales on Linux. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 22:29 Message: Logged In: YES user_id=33168 Martin, should this be closed? Is there a bug? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-08 04:55 Message: Logged In: YES user_id=21627 I see. For that, you should not use getdefaultlocale. The reason is that getdefaultlocale cannot possibly determine the locale's encoding correctly. Instead, you should use locale.nl_langinfo where available (invoking setlocale beforehand). The fix you are reporting as 'easy' is a hack rather than a solution: there is no guarantee whatsoever that the encoding in a @euro locale will be Latin-9; it could just as well be, say, UTF-8. Likewise, there might be other locales with implied encodings. ---------------------------------------------------------------------- Comment By: Chema Cortés (chemacortes) Date: 2002-07-05 21:11 Message: Logged In: YES user_id=78289 We, as non-english writers, need 'getdefaultlocale' to set the default encoding for unicode strings: lang,encoding=locale.getdefaultlocale() sys.setdefaultencoding(encoding) The problem can be fixed easyly by insert the new locales into the locale_alias of module locale: locale_alias={ ... "de_de@euro": "de_DE.iso8859_15", "de_at@euro": "de_AT@iso8859_15", "es_es@euro":"es_ES@iso8859_15", ... } As a workarround, you can modify the locale_alias into the sitecustomize.py # adding euro locales import locale eurolocs=[ "ca_ES", "da_DK", "de_AT", "de_BE", "de_DE", "de_LU", "en_BE", "en_IE", "es_ES", "eu_ES", "fi_FI", "fr_BE", "fr_FR", "fr_LU", "ga_IE", "gl_ES", "it_IT", "nl_BE", "nl_NL", "pt_PT", "sv_FI" ] for l in eurolocs: key=l.lower()+"@euro" # eg: "es_es@euro" cod=l+".iso8859_15" # eg: "es_ES.iso8859_15" locale.locale_alias[key]=cod # Setting the unicode default encoding import sys if hasattr(sys,"setdefaultencoding"): lang,encoding=locale.getdefaultlocale() sys.setdefaultencoding(encoding) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-09 05:10 Message: Logged In: YES user_id=21627 Can you please explain what you need getdefaultlocale for? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470 From noreply@sourceforge.net Sun Nov 3 04:40:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 20:40:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 12:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-02 21:40 Message: Logged In: YES user_id=85984 The problem was under Python 2.2. Though now the user reports that he can no longer reproduce the problem, despite not having done any Python upgrades or system configuration changes. We might just have to chuck this one up to FM (Funny Magic). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 14:14 Message: Logged In: YES user_id=33168 Jason, still with us? What version of python were you having the problem with? 2.1.x? 2.2.x? Do you have the problem with 2.2? Have you looked at patch #604210 (http://python.org/604210)? Can you test that? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-06 18:20 Message: Logged In: YES user_id=85984 Still having the problem, but I'm unsure how to proceed. nslookup and host both return instantly when querying datavortex.net. Only Python seems to exhibit this problem, but it still could be a system misconfiguration. This is the only time I've ever seen/heard of this behavior. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 16:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 16:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 13:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 15:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 15:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 10:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 15:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 15:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply@sourceforge.net Sun Nov 3 05:06:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 21:06:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-564729 ] FixTk.py logic wrong Message-ID: Bugs item #564729, was opened at 2002-06-05 06:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470 Category: Tkinter Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: FixTk.py logic wrong Initial Comment: The logic in FixTk.py is wrong for Tix: the Tix version number is independent of the Tk/Tcl version number. Just duplicate the Tcl code logic for Tix, and don't reuse the Tcl version number. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:06 Message: Logged In: YES user_id=33229 Sorry for the lack of detail: the logic is wrong because the version number of Tix is assumed to be the same as the version number of Tcl in _tkinter. Right now they are different (8.3 or 8.4 for Tcl and 8.1 for Tix) and in general these days with stubs in Tcl, they are unrelated. Any Tix should work with any Tcl after Tcl 8.1 or so. So the answer is to remove tix from the for loop, and just copy the Tcl block of logic and change the tcl to tix as in the following (untested) if not os.environ.has_key("TIX_LIBRARY"): for name in os.listdir(prefix): if name.startswith("tix"): tixdir = os.path.join(prefix,name) if os.path.isdir(tixdir): os.environ["TIX_LIBRARY"] = tixdir del tixdir Note that as it stands now there is a subtle difference between the logic for setting TCL_LIBRARY and for setting TK_LIBRARY (ignoring tix completely). Imagine you have a Tcl directory with no environment variables and the following subdirs: tcl8.3 tcl8.4 tk8.3 tk8.4 If os.listddir returns the directories in alphabetical order I think you end up with TCL_LIBRARY=.../tcl8.4 (there's no break in the for name loop) and TK_LIBRARY=.../tk8.3 if tk was compiled with tcl 8.3 (_tkinter.TCL_VERSION) With Tk8.4 now finally released this a real potential scenario. This may be good or bad - the attached file maintains it. The discussion above and the attached file applies to all versions of Python, so it should be tagged for any 2.x branch. I think the same is true for Tix.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 19:25 Message: Logged In: YES user_id=6380 Can you please supply a patch? The code in 2.2 and later is different; is that still broken? If so, please supply two patches! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470 From noreply@sourceforge.net Sun Nov 3 05:14:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 21:14:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter (?) refct (?) bug Message-ID: Bugs item #632323, was opened at 2002-11-01 22:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter (?) refct (?) bug Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 04:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sun Nov 3 05:34:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 21:34:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 11:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 03:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 01:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 13:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 12:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 12:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 11:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 18:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply@sourceforge.net Sun Nov 3 06:52:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 22:52:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown Message-ID: Bugs item #231207, was opened at 2001-02-06 02:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Henderson (djhender) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python Error during program shutdown Initial Comment: The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a event or call to a ?.destory() function. Under Windows 98SE, this results in a GPF. Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate". The following script demonstrates the problem: --------------------- # BugDemo.py from Tkinter import * class BugDemo(Frame): def __init__(self, parent): Frame.__init__(self, parent) Button(self, text='Hi', command=self.hi).pack() Button(self, text='Quit', command=self.tk.quit).pack() def hi(self): print "hi" bd = BugDemo(Tk()) bd.pack() bd.mainloop() ---------------------- Execute in console window: "c:> python BugDemo.py" Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button. Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly. Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time. The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem. Problem also manifests using the PythonWare 2.0 release on Win98. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:52 Message: Logged In: YES user_id=33229 I know I'm a Python newbie but I know Tcl well and I think I know at least part of what's going on. Looking specifically at nobody's 2002-04-22 14:21 code, I see that this uses mainloop and quit in a way that many Python books and examples do, as if quit() will "Quit the Tcl interpreter. All widgets will be destroyed." But if you look at MainLoop and Quit in _tkinter.c you see that Quit just sets a variable that causes MainLoop to end - it doesn't destroy anything nor quit the interpreter. IMHO all Tkinter programs need a root.destroy() after root.mainloop() If you change nobody's program to add a root.destroy() it runs fine under PythonWin. The "bug" is in the documentation of quit() in Tkinter.py def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self.tk.quit() The comment should read """Quit the main event loop. It is up to you to call root.destroy() after.""" If I'm right the documentation for Tkinter in the library reference should be changed too; there should be a root.destroy() at the end of http://www.python.org/doc/2.2.1/lib/node503.html If I'm right then I'll stick my neck out a little further: Tkinter's mainloop and quit should be dropped from _tkinter.c and replaced with the following idiom and usage: In Tkinter.py declare a class variable in Misc: _exit = -1 and change in Misc TCL_ALL_EVENTS = 0 def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self._exit = 0 def mainloop(self): """Loop until we call quit()""" while self._exit < 0: try: self.root.tk.dooneevent(TCL_ALL_EVENTS) except SystemExit: #print 'Exit' self.exit = 1 break except # do something intelligent with errors or interrupts I believe this is more transparent and more open to creativity. I have experimented (all my code is like this now) and feel that there is no performance penalty to looping in Python. In addition it avoids the 20msec sleep in _tkinter.mainloop() that is an abomination. It would also allow people to think more clearly about what happens when you have 2 Tk() instances, in which case you have 2 Tcl interpeters. It may make you move _exit to be an instance variable of the Tk class. In any event you'll be able to see what's going on. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 14:21 Message: Logged In: NO I confirm the behaviour for: WinNT 4.0 SP5 tested with Python 2.2Beta1 (ActiveState) tested with Python 2.2.1.222 (ActiveState) PythonWinIDE will hang when the following program is "quit"ted. But will "quit" normally when run standalone (not within PythonWinIDE): # # from Tkinter import * from tkMessageBox import * class App: def __init__(self, winRoot): frame = Frame(winRoot) frame.pack() self.btnQuit = Button(frame, text="QUIT", bg="blue", foreground="light blue", command=frame.quit) self.btnQuit.pack(side=LEFT) self.btnHiThere = Button(frame, text="Hi there!",command=self.sayHiThere) self.btnHiThere.pack(side=LEFT) def sayHiThere(self): showinfo("Greeting", "Hi There") if __name__ == "__main__": root = Tk() test = App(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 22:49 Message: Logged In: YES user_id=31392 Unassign as it appears that effbot isn't going to look at it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-18 11:13 Message: Logged In: NO i won't to be a hacker ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-29 07:30 Message: Logged In: NO Note: I am running Windows98 ActivePython 2.1 Even with console apps in python this same error appears I tried using another Distribution of Python for win32, PythonWare20 So this leads me to believe that some lib is missing on win98. Because at work I use Win95, and Installed ActivePython 2.1, and it works fine and dandy ---------------------------------------------------------------------- Comment By: Joel Gould (joelgould) Date: 2001-03-24 16:52 Message: Logged In: YES user_id=20954 I also see a GPF on shutdown under Windows 98 using Tkinter. I tested this using the PythonWare 2.0 release as well. I have attached a very simple Tkinter program. When I run this on my Windows 98 SE machine, a crash occurs when the program exits. Without the MainDialog class it works OK. Without the Pmw initialization call it works OK. But as written it will crash around 75% of the time. (1) run the program (2) press the Test Button (3) click Cancel in the file open dialog (you do not need to select a file) (4) click the close button in the upper right corner --> Boom -------------------- import Tkinter import tkFileDialog import Pmw def action(): tkFileDialog.askopenfilename(filetypes=[('All','*')]) class MainDialog: def __init__(self,parent): Tkinter.Button(parent,text='Test Button',command=action).pack() root = Pmw.initialise() dialog = MainDialog(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-09 23:34 Message: Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-06 05:30 Message: See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 From noreply@sourceforge.net Sun Nov 3 07:30:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Nov 2002 23:30:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 11:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 07:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 03:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 01:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 13:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 12:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 12:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 11:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 18:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply@sourceforge.net Sun Nov 3 08:02:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 00:02:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-554676 ] unknown locale de_DE@euro on Suse 8.0 Linux Message-ID: Bugs item #554676, was opened at 2002-05-10 23:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent wehren (vinweh) Assigned to: Martin v. Löwis (loewis) Summary: unknown locale de_DE@euro on Suse 8.0 Linux Initial Comment: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 When calling the locale module's getdefaultlocale() method on SuSe 8.0 Linux you get: >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/locale.py", line 337, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.2/locale.py", line 271, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: de_DE@euro Evidently, Python2.2's locale module is unaware of the "somelang_SOMELANG@euro" nomenclature for euro-enabled locales on Linux. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 09:02 Message: Logged In: YES user_id=21627 There is a shallow bug, namely that locale._parse_localename("de_DE@euro") crashes; it should return the same value that it does for de_DE, or perhaps it should have hard-coded knowledge that the codeset is iso-8859-15. There is a deeper underlying bug that getdefaultlocale is a hopeless case. I'll be adding a locale.getpreferredencoding function to make getdefaultlocale unnecessary. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 04:29 Message: Logged In: YES user_id=33168 Martin, should this be closed? Is there a bug? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-08 10:55 Message: Logged In: YES user_id=21627 I see. For that, you should not use getdefaultlocale. The reason is that getdefaultlocale cannot possibly determine the locale's encoding correctly. Instead, you should use locale.nl_langinfo where available (invoking setlocale beforehand). The fix you are reporting as 'easy' is a hack rather than a solution: there is no guarantee whatsoever that the encoding in a @euro locale will be Latin-9; it could just as well be, say, UTF-8. Likewise, there might be other locales with implied encodings. ---------------------------------------------------------------------- Comment By: Chema Cortés (chemacortes) Date: 2002-07-06 03:11 Message: Logged In: YES user_id=78289 We, as non-english writers, need 'getdefaultlocale' to set the default encoding for unicode strings: lang,encoding=locale.getdefaultlocale() sys.setdefaultencoding(encoding) The problem can be fixed easyly by insert the new locales into the locale_alias of module locale: locale_alias={ ... "de_de@euro": "de_DE.iso8859_15", "de_at@euro": "de_AT@iso8859_15", "es_es@euro":"es_ES@iso8859_15", ... } As a workarround, you can modify the locale_alias into the sitecustomize.py # adding euro locales import locale eurolocs=[ "ca_ES", "da_DK", "de_AT", "de_BE", "de_DE", "de_LU", "en_BE", "en_IE", "es_ES", "eu_ES", "fi_FI", "fr_BE", "fr_FR", "fr_LU", "ga_IE", "gl_ES", "it_IT", "nl_BE", "nl_NL", "pt_PT", "sv_FI" ] for l in eurolocs: key=l.lower()+"@euro" # eg: "es_es@euro" cod=l+".iso8859_15" # eg: "es_ES.iso8859_15" locale.locale_alias[key]=cod # Setting the unicode default encoding import sys if hasattr(sys,"setdefaultencoding"): lang,encoding=locale.getdefaultlocale() sys.setdefaultencoding(encoding) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-09 11:10 Message: Logged In: YES user_id=21627 Can you please explain what you need getdefaultlocale for? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470 From noreply@sourceforge.net Sun Nov 3 08:08:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 00:08:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 11:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) >Assigned to: Neal Norwitz (nnorwitz) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 09:08 Message: Logged In: YES user_id=21627 Neal, can you try to reproduce this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:20 Message: Logged In: YES user_id=21627 Any news on this? Can you please try Python 2.2 and report how that works? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-02-14 01:04 Message: Logged In: YES user_id=29957 Unless someone with a) fairly deep knowledge of HP/UX, b) access to a HP/UX machine and c) the spare time and effort to debug this steps forward, the chances of this being fixed are zero. (I still think adding a resolution of 'HP/UX' to the bug tracker would allow us to close a whooole lotta bugs) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-13 02:45 Message: Logged In: YES user_id=21627 This problem looks very much like a HP-UX bug. It crashes inside the malloc implementation, and not only that: it also crashes inside the thread mutex used by malloc. I would guess there is nothing we can do about this; please ask HP for advise (or just don't use threads if they don't work) ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-02-12 21:08 Message: Logged In: YES user_id=436029 Hi, I've thought threads now work! But I think they don't! I use python 2.1.2 with Zope. Now sometimes it works. But when i add a CMF-Object I get a core dump. So I've startetd gdb and here is the log: jojo 22: gdb /opt/zope/bin/python2.1 core HP gdb 2.0 Copyright 1986 - 1999 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 2.0 (based on GDB 4.17-hpwdb-980821) Wildebeest is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for Wildebeest. Type "show warranty" for details. Wildebeest was built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00. .. Core was generated by `python2.1'. Program terminated with signal 10, Bus error. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 (gdb) bt #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 #1 0xc0123ed0 in __thread_mutex_lock () from /usr/lib/libc.2 #2 0xc00a0018 in _sigfillset () from /usr/lib/libc.2 #3 0xc009e22c in _memset () from /usr/lib/libc.2 #4 0xc00a37d8 in malloc () from /usr/lib/libc.2 #5 0x3bad0 in PyFrame_New (tstate=0x0, code=0x0, globals=0x0, locals=0x0) at Objects/frameobject.c:149 #6 0xc0123f94 in __thread_mutex_unlock () from /usr/lib/libc.2 #7 (gdb) I don't know if this is a python or zope Problem and I dont't know if this bug is at the right position. Please help. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 11:41 Message: Logged In: YES user_id=436029 Fileupload config.h ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 11:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 20:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 15:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 10:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 09:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-24 08:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 16:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Sun Nov 3 11:06:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 03:06:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit Message-ID: Bugs item #453489, was opened at 2001-08-20 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using deiconify() hangs on exit Initial Comment: If you run the following script, and iconize the window before the after() timer, it'll restore and raise the window as it should, but then you can't exit. You have to kill winoldap with ctrl+alt+del and wait. I ran into this trying to write a portable jabber client using tkinter. This is with 2.1.1 on Windows 98. Does it every time. May be related to bug #216289. from Tkinter import * import sys def foo(): print 'foo' sys.stdout.flush() root.deiconify() print 'bar' sys.stdout.flush() root=Tk() Button(root, text='Quit', command=root.quit).pack() root.after(5000, foo) root.mainloop() ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 11:06 Message: Logged In: YES user_id=33229 See my comments in bug 231207: IMHO all Tkinter programs need a root.destroy() after root.mainloop() Your test case DOES NOT die whether or not you deiconify it, if you run it under PythonWin. Your test case DOES die whether or not you deiconify it, whether or not you run it under PythonWin, if you add a root.destroy() after the root.mainloop() If you run it as a console script without the root.destroy() then Python reaches the end of the script and exits, without having shut Tk down first. PythonWin of course is not exiting at the end, and in the status line says the script returns with code 0. I think this is a usage/documentation error and is IMHO unrelated to the very real bug 216289. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 18:31 Message: Logged In: YES user_id=66570 Since I was also looking at #216289: Data using pythonw.exe (Taskinfo2000): Handles while running (before quit) 4 : Process 4 PID:FFF6F92D, C:\PYTHON20\PYTHONW.EXE C : Event 1 10 : Event 1 1C : Mutex 17 OLESCMLOCKMUTEX 20 : Event 1 24 : Event 1 -------------------------------------------------------- Handles while running Python.exe (before quit) |Handle||Type| |Refs||Name| 4 : Process 7 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 2 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 ThID:FFF79069, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 38 : Event 1 3C : Event 2 40 : Thread 1 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 44 : Event 1 48 : Event 2 4C : Thread 1 ThID:FFF53539, PID:FFF50719, C:\PYTHON20\PYTHON.EXE ---------------------------------------------------------- Handles AFTER trying to quit |Handle||Type| |Refs||Name| 4 : Process 4 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 1 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 38 : Event 1 3C : Event 1 40 : Thread 2 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE It appears that there is a thread NOT terminating. I just don't know how to go about finding it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-21 02:39 Message: Logged In: YES user_id=6380 I agree that this is likely the same as #216289. AFAIK it's a Tcl bug and we don't know what to do about it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-20 22:51 Message: Logged In: NO Interestingly enough, if you add a print statement after the mainloop(), it gets printed, showing the event loop exits properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 From noreply@sourceforge.net Sun Nov 3 12:41:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 04:41:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-632864 ] Typo string instead of sting in LibDoc Message-ID: Bugs item #632864, was opened at 2002-11-03 12:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632864&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Barth (peterbarth) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Typo string instead of sting in LibDoc Initial Comment: Typo: strings instead of stings in section 16.1.6.6 Tk Option Data Types in the Python Library Reference http://www.python.org/doc/current/lib/node520.html --- This --- boolean You can pass integers 0 or 1 or the stings "yes" or "no". --- should read boolean You can pass integers 0 or 1 or the strings "yes" or "no". --- Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632864&group_id=5470 From noreply@sourceforge.net Sun Nov 3 12:57:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 04:57:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky Message-ID: Bugs item #549038, was opened at 2002-04-26 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Ka-Ping Yee (ping) Summary: cgitb variable dumps a little flaky Initial Comment: First off, easy problem: lookup() should look in frame.f_globals["__builtins__"] also. Along the same lines, I am not sure if lookup works properly with nested scopes, but since I don't use nested scopes in any of my code this is not a problem for me ;-) Secondly, the parsing in scanvars() is somewhat hacky. For example, given the following line: foo(open(filename).read()) it will think the following variables exist: foo open filename ).read Obviously this last one is incorrect. I am not sure if this is easy to fix or not. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-03 12:57 Message: Logged In: YES user_id=76089 Whether it is fixed or not depends on whether you think it is a bug or not ;-) It could possibly be considered a feature request. Looking at CVS, the first point is fixed, the second is not. I am not sure how difficult it is to detect the variable names in the source code "properly" - if it's easy then I guess this is a bug report, if it's hard it's a feature request. I won't argue if this is closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 03:28 Message: Logged In: YES user_id=33168 Jon, is this fixed? Can it be closed? If not, what do you think needs to be done? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-06-26 11:28 Message: Logged In: YES user_id=76089 I'm not quite sure why you were unable to reproduce the ").read" bit. Try the following code: import cgitb; cgitb.enable() filename = "foo" foo(open(filename).read()) The output includes: foo undefined, open undefined, filename = 'foo', ).read undefined Do you get something different? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-06-26 08:11 Message: Logged In: YES user_id=45338 The lookup function looks in frame.f_locals, which does the right thing with respect to nested scopes as far as i can tell. I tested the parser and wasn't able to reproduce the problem you described. Thanks for the bug report. I have committed a change that adds the lookup in __builtins__. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:50 Message: Logged In: YES user_id=6380 Nobody except Ka-Ping Ping understands the code in cgitb.py, so I suggest that you track him down and get him to look at this bug report. In the past I've performed this service myself but I'm getting tired of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470 From noreply@sourceforge.net Sun Nov 3 13:14:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 05:14:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-632864 ] Typo string instead of sting in LibDoc Message-ID: Bugs item #632864, was opened at 2002-11-03 07:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632864&group_id=5470 Category: Documentation >Group: Python 2.2.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter Barth (peterbarth) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo string instead of sting in LibDoc Initial Comment: Typo: strings instead of stings in section 16.1.6.6 Tk Option Data Types in the Python Library Reference http://www.python.org/doc/current/lib/node520.html --- This --- boolean You can pass integers 0 or 1 or the stings "yes" or "no". --- should read boolean You can pass integers 0 or 1 or the strings "yes" or "no". --- Cheers ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 08:14 Message: Logged In: YES user_id=33168 Thanks. Checked in as: Doc/lib/tkinter.tex 1.16 and 1.10.6.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632864&group_id=5470 From noreply@sourceforge.net Sun Nov 3 17:24:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 09:24:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-554676 ] unknown locale de_DE@euro on Suse 8.0 Linux Message-ID: Bugs item #554676, was opened at 2002-05-10 23:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: vincent wehren (vinweh) Assigned to: Martin v. Löwis (loewis) Summary: unknown locale de_DE@euro on Suse 8.0 Linux Initial Comment: Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 When calling the locale module's getdefaultlocale() method on SuSe 8.0 Linux you get: >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/locale.py", line 337, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.2/locale.py", line 271, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: de_DE@euro Evidently, Python2.2's locale module is unaware of the "somelang_SOMELANG@euro" nomenclature for euro-enabled locales on Linux. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 18:24 Message: Logged In: YES user_id=21627 This is now fixed in locale.py 1.22 and 1.19.16.1; test_locale.py 1.5; NEWS 1.506; liblocale.tex 1.31; The @euro modifier will now imply Latin-9; as indicated, this might be bogus, but is better than the current behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 09:02 Message: Logged In: YES user_id=21627 There is a shallow bug, namely that locale._parse_localename("de_DE@euro") crashes; it should return the same value that it does for de_DE, or perhaps it should have hard-coded knowledge that the codeset is iso-8859-15. There is a deeper underlying bug that getdefaultlocale is a hopeless case. I'll be adding a locale.getpreferredencoding function to make getdefaultlocale unnecessary. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 04:29 Message: Logged In: YES user_id=33168 Martin, should this be closed? Is there a bug? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-08 10:55 Message: Logged In: YES user_id=21627 I see. For that, you should not use getdefaultlocale. The reason is that getdefaultlocale cannot possibly determine the locale's encoding correctly. Instead, you should use locale.nl_langinfo where available (invoking setlocale beforehand). The fix you are reporting as 'easy' is a hack rather than a solution: there is no guarantee whatsoever that the encoding in a @euro locale will be Latin-9; it could just as well be, say, UTF-8. Likewise, there might be other locales with implied encodings. ---------------------------------------------------------------------- Comment By: Chema Cortés (chemacortes) Date: 2002-07-06 03:11 Message: Logged In: YES user_id=78289 We, as non-english writers, need 'getdefaultlocale' to set the default encoding for unicode strings: lang,encoding=locale.getdefaultlocale() sys.setdefaultencoding(encoding) The problem can be fixed easyly by insert the new locales into the locale_alias of module locale: locale_alias={ ... "de_de@euro": "de_DE.iso8859_15", "de_at@euro": "de_AT@iso8859_15", "es_es@euro":"es_ES@iso8859_15", ... } As a workarround, you can modify the locale_alias into the sitecustomize.py # adding euro locales import locale eurolocs=[ "ca_ES", "da_DK", "de_AT", "de_BE", "de_DE", "de_LU", "en_BE", "en_IE", "es_ES", "eu_ES", "fi_FI", "fr_BE", "fr_FR", "fr_LU", "ga_IE", "gl_ES", "it_IT", "nl_BE", "nl_NL", "pt_PT", "sv_FI" ] for l in eurolocs: key=l.lower()+"@euro" # eg: "es_es@euro" cod=l+".iso8859_15" # eg: "es_ES.iso8859_15" locale.locale_alias[key]=cod # Setting the unicode default encoding import sys if hasattr(sys,"setdefaultencoding"): lang,encoding=locale.getdefaultlocale() sys.setdefaultencoding(encoding) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-09 11:10 Message: Logged In: YES user_id=21627 Can you please explain what you need getdefaultlocale for? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470 From noreply@sourceforge.net Sun Nov 3 17:26:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 09:26:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not assigned to global? Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) >Summary: Tkinter: BitmapImage vanishes if not assigned to global? Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 21:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sun Nov 3 19:42:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 11:42:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) >Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 11:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 21:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sun Nov 3 21:09:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 13:09:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 05:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Neal Norwitz (nnorwitz) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 16:09 Message: Logged In: YES user_id=33168 I've built python 2.3 --with-threads, with the HP cc (-Ae), modified Makefile to add -D_REENTRANT (although it was already in pyconfig.h). I did this on the Compaq test drive machine: spe169.testdrive.compaq.com. It is HP-UX 11i on rp2470 PA RISC w/2 CPUs. There are some test problems: * test_nis crashes the interpreter (I need to look into this) * test_tempfile fails due to too many open files - the problem is that __del__ tries to delete self.fd which doesn't exist * test_pwd fails w/wrong output: - caught expected exception + fakeuid 4127 did not except pwd.getpwuid() Just running test_thread.py works for me. Is it possible to disable threads at the OS level in HPUX? Can threads be used from C on this platform? I will try 2.2.2 next. I will also try on the snake farm, but that is gcc. Stefan, do you have this problem with python 2.2.2? Are you still having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 03:08 Message: Logged In: YES user_id=21627 Neal, can you try to reproduce this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 05:20 Message: Logged In: YES user_id=21627 Any news on this? Can you please try Python 2.2 and report how that works? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-02-13 19:04 Message: Logged In: YES user_id=29957 Unless someone with a) fairly deep knowledge of HP/UX, b) access to a HP/UX machine and c) the spare time and effort to debug this steps forward, the chances of this being fixed are zero. (I still think adding a resolution of 'HP/UX' to the bug tracker would allow us to close a whooole lotta bugs) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-12 20:45 Message: Logged In: YES user_id=21627 This problem looks very much like a HP-UX bug. It crashes inside the malloc implementation, and not only that: it also crashes inside the thread mutex used by malloc. I would guess there is nothing we can do about this; please ask HP for advise (or just don't use threads if they don't work) ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-02-12 15:08 Message: Logged In: YES user_id=436029 Hi, I've thought threads now work! But I think they don't! I use python 2.1.2 with Zope. Now sometimes it works. But when i add a CMF-Object I get a core dump. So I've startetd gdb and here is the log: jojo 22: gdb /opt/zope/bin/python2.1 core HP gdb 2.0 Copyright 1986 - 1999 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 2.0 (based on GDB 4.17-hpwdb-980821) Wildebeest is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for Wildebeest. Type "show warranty" for details. Wildebeest was built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00. .. Core was generated by `python2.1'. Program terminated with signal 10, Bus error. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 (gdb) bt #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 #1 0xc0123ed0 in __thread_mutex_lock () from /usr/lib/libc.2 #2 0xc00a0018 in _sigfillset () from /usr/lib/libc.2 #3 0xc009e22c in _memset () from /usr/lib/libc.2 #4 0xc00a37d8 in malloc () from /usr/lib/libc.2 #5 0x3bad0 in PyFrame_New (tstate=0x0, code=0x0, globals=0x0, locals=0x0) at Objects/frameobject.c:149 #6 0xc0123f94 in __thread_mutex_unlock () from /usr/lib/libc.2 #7 (gdb) I don't know if this is a python or zope Problem and I dont't know if this bug is at the right position. Please help. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 05:41 Message: Logged In: YES user_id=436029 Fileupload config.h ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 05:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 14:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 09:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 04:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 03:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-24 02:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 10:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Sun Nov 3 22:05:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 14:05:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 05:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Neal Norwitz (nnorwitz) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 17:05 Message: Logged In: YES user_id=33168 I'm guessing test_pwd fails because there are over 40000 users on the system. I posted a patch (633013) to fix the nis problem. The test_tempfile is a weird interaction with the test framework and not really a problem I think. I ran 2.2.2 on a different box: B.11.00 A 9000/829. This used gcc 2.95.2. It also didn't have a problem. Neither with the regression tests nor running test_thread standalone. My current thoughts are this is either a 2.1.x problem or is specific to Stefan's box. If we don't hear back from Stefan by Nov 20 or so, I will close this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 16:09 Message: Logged In: YES user_id=33168 I've built python 2.3 --with-threads, with the HP cc (-Ae), modified Makefile to add -D_REENTRANT (although it was already in pyconfig.h). I did this on the Compaq test drive machine: spe169.testdrive.compaq.com. It is HP-UX 11i on rp2470 PA RISC w/2 CPUs. There are some test problems: * test_nis crashes the interpreter (I need to look into this) * test_tempfile fails due to too many open files - the problem is that __del__ tries to delete self.fd which doesn't exist * test_pwd fails w/wrong output: - caught expected exception + fakeuid 4127 did not except pwd.getpwuid() Just running test_thread.py works for me. Is it possible to disable threads at the OS level in HPUX? Can threads be used from C on this platform? I will try 2.2.2 next. I will also try on the snake farm, but that is gcc. Stefan, do you have this problem with python 2.2.2? Are you still having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 03:08 Message: Logged In: YES user_id=21627 Neal, can you try to reproduce this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 05:20 Message: Logged In: YES user_id=21627 Any news on this? Can you please try Python 2.2 and report how that works? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-02-13 19:04 Message: Logged In: YES user_id=29957 Unless someone with a) fairly deep knowledge of HP/UX, b) access to a HP/UX machine and c) the spare time and effort to debug this steps forward, the chances of this being fixed are zero. (I still think adding a resolution of 'HP/UX' to the bug tracker would allow us to close a whooole lotta bugs) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-12 20:45 Message: Logged In: YES user_id=21627 This problem looks very much like a HP-UX bug. It crashes inside the malloc implementation, and not only that: it also crashes inside the thread mutex used by malloc. I would guess there is nothing we can do about this; please ask HP for advise (or just don't use threads if they don't work) ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-02-12 15:08 Message: Logged In: YES user_id=436029 Hi, I've thought threads now work! But I think they don't! I use python 2.1.2 with Zope. Now sometimes it works. But when i add a CMF-Object I get a core dump. So I've startetd gdb and here is the log: jojo 22: gdb /opt/zope/bin/python2.1 core HP gdb 2.0 Copyright 1986 - 1999 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 2.0 (based on GDB 4.17-hpwdb-980821) Wildebeest is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for Wildebeest. Type "show warranty" for details. Wildebeest was built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00. .. Core was generated by `python2.1'. Program terminated with signal 10, Bus error. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 (gdb) bt #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 #1 0xc0123ed0 in __thread_mutex_lock () from /usr/lib/libc.2 #2 0xc00a0018 in _sigfillset () from /usr/lib/libc.2 #3 0xc009e22c in _memset () from /usr/lib/libc.2 #4 0xc00a37d8 in malloc () from /usr/lib/libc.2 #5 0x3bad0 in PyFrame_New (tstate=0x0, code=0x0, globals=0x0, locals=0x0) at Objects/frameobject.c:149 #6 0xc0123f94 in __thread_mutex_unlock () from /usr/lib/libc.2 #7 (gdb) I don't know if this is a python or zope Problem and I dont't know if this bug is at the right position. Please help. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 05:41 Message: Logged In: YES user_id=436029 Fileupload config.h ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 05:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 14:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 09:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 04:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 03:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-24 02:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 10:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Mon Nov 4 01:26:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 17:26:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky Message-ID: Bugs item #549038, was opened at 2002-04-26 08:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Ka-Ping Yee (ping) Summary: cgitb variable dumps a little flaky Initial Comment: First off, easy problem: lookup() should look in frame.f_globals["__builtins__"] also. Along the same lines, I am not sure if lookup works properly with nested scopes, but since I don't use nested scopes in any of my code this is not a problem for me ;-) Secondly, the parsing in scanvars() is somewhat hacky. For example, given the following line: foo(open(filename).read()) it will think the following variables exist: foo open filename ).read Obviously this last one is incorrect. I am not sure if this is easy to fix or not. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 20:26 Message: Logged In: YES user_id=33168 I'll close this bug report. If you want the feature added, feel free to submit a patch. :-) Thanks. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-03 07:57 Message: Logged In: YES user_id=76089 Whether it is fixed or not depends on whether you think it is a bug or not ;-) It could possibly be considered a feature request. Looking at CVS, the first point is fixed, the second is not. I am not sure how difficult it is to detect the variable names in the source code "properly" - if it's easy then I guess this is a bug report, if it's hard it's a feature request. I won't argue if this is closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 22:28 Message: Logged In: YES user_id=33168 Jon, is this fixed? Can it be closed? If not, what do you think needs to be done? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-06-26 06:28 Message: Logged In: YES user_id=76089 I'm not quite sure why you were unable to reproduce the ").read" bit. Try the following code: import cgitb; cgitb.enable() filename = "foo" foo(open(filename).read()) The output includes: foo undefined, open undefined, filename = 'foo', ).read undefined Do you get something different? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-06-26 03:11 Message: Logged In: YES user_id=45338 The lookup function looks in frame.f_locals, which does the right thing with respect to nested scopes as far as i can tell. I tested the parser and wasn't able to reproduce the problem you described. Thanks for the bug report. I have committed a change that adds the lookup in __builtins__. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:50 Message: Logged In: YES user_id=6380 Nobody except Ka-Ping Ping understands the code in cgitb.py, so I suggest that you track him down and get him to look at this bug report. In the past I've performed this service myself but I'm getting tired of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470 From noreply@sourceforge.net Mon Nov 4 07:26:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Nov 2002 23:26:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Mon Nov 4 08:19:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 00:19:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 09:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Mon Nov 4 08:22:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 00:22:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-614051 ] win32 build_ext problem Message-ID: Bugs item #614051, was opened at 2002-09-24 23:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614051&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Thomas Heller (theller) Summary: win32 build_ext problem Initial Comment: From: Andy Miller To: jeremy@alum.mit.edu Subject: Bug in build_ext.py Date: Tue, 10 Sep 2002 03:25:46 -0700 In the last CVS version of build_ext.py you changed the get_libraries function to read: if sys.platform == "win32": from distutils.msvccompiler import MSVCCompiler if not isinstance(self.compiler, MSVCCompiler): template = "python%d%d" It also needs an else assocated with the "if not isinstance" else: return ext.libraries Otherwise if an installer has defined their own compiler (or is not using MSVC I suppose) then none of the libraries are passed to the link stage - I discovered this with the WxPython modules. The previous version of build_ext used to fallout the bottom with the "return ext.libraries" while with the current version you get a 'None' if Win32 and NOT MSVC Cheers Andy ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-04 09:22 Message: Logged In: YES user_id=11105 Closing as fixed. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-31 15:28 Message: Logged In: YES user_id=11105 I've checked in a patch: build_ext.py, rev 1.86. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614051&group_id=5470 From noreply@sourceforge.net Mon Nov 4 09:11:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 01:11:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-625823 ] missing names in telnetlib.py Message-ID: Bugs item #625823, was opened at 2002-10-20 07:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing names in telnetlib.py Initial Comment: The telnet RFC (854 -- http://www.faqs.org/rfcs/rfc854.html) details eleven constants for the telnet protocol that are not included in the telnetlib module. The attached patch adds them. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 10:11 Message: Logged In: YES user_id=21627 How did you come up with the symbolic names for these constants? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 From noreply@sourceforge.net Mon Nov 4 10:02:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 02:02:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-633182 ] Memory leak with weakref Message-ID: Bugs item #633182, was opened at 2002-11-04 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633182&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak with weakref Initial Comment: With Python 2.2.2 on Windows 2000, this code leaks 52 bytes of memory for each instance of class foo. <> import weakref, sys class foo: def __init__(self): self.wref = weakref.WeakValueDictionary() self.wref[id(self)] = self l = [foo() for x in range(int(sys.argv[1]))] for i in l: i.wref.clear() del i.wref del l import gc gc.collect() <> These reports are printed by msvc's _CrtMemDumpStatistics() function. C:\>python_d a.py 200 Adding parser accelerators ... Done. [4504 refs] 0 bytes in 0 Free Blocks. 85405 bytes in 1002 Normal Blocks. 4528 bytes in 15 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 556766 bytes. Total allocations: 1300386 bytes. C:\>python_d a.py 300 Adding parser accelerators ... Done. [4504 refs] 0 bytes in 0 Free Blocks. 95805 bytes in 1202 Normal Blocks. 4528 bytes in 15 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 635950 bytes. Total allocations: 1401070 bytes. Current cvs version of Python doesn't leak (with or without PyMalloc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633182&group_id=5470 From noreply@sourceforge.net Mon Nov 4 10:17:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 02:17:18 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-623782 ] os.utime() that works on symlinks? Message-ID: Feature Requests item #623782, was opened at 2002-10-15 23:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=623782&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Rob Landley (landley) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime() that works on symlinks? Initial Comment: I can query a symlink's timestamps with os.lstat(), but can't set them. Any attempt to set the timestamps on a symlink is transparently redirected to the file it points to (which in this case is on a read-only partition, as is not what I want to do anyway). Maybe os.lutime()? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 11:17 Message: Logged In: YES user_id=21627 It's not possible to implement this feature: the operating system provides no mechanism to modify the timestamp of a symlink. The closest you can get is to remove and recreate the symlink, but that uses the current time, not the one you would give to utime. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-10-16 00:10 Message: Logged In: YES user_id=45365 Is there a way to do this from a C program? os.utime() is simply a wrapper around the C library call of the same name, and I'm not aware of a lutime() on systems I'm familiar with... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=623782&group_id=5470 From noreply@sourceforge.net Mon Nov 4 10:29:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 02:29:56 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-622230 ] def object.new_method(self): Message-ID: Feature Requests item #622230, was opened at 2002-10-12 08:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: def object.new_method(self): Initial Comment: I want to be able to create functions inside objects instead of having to do: class x: pass def new_method(self): pass x.new_method = new_method del new_method I want to do: class x: pass def x.new_method(self): pass Why isn't this possible? Wouldn't it be cool? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 11:29 Message: Logged In: YES user_id=21627 It's simply not possible because nobody has though of that. I personally would not consider it cool: Python expresses nesting of definition with indentation, not with full-stop separators. Unless you implement it yourself, I'd expect that it is unlilkely that anybody will act on this request in the coming years. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2002-10-12 08:08 Message: Logged In: YES user_id=118203 Repost with attempted better formatting: I don't want to do: class x:     pass def new_method(self):     pass x.new_method = new_method del new_method I want to do: class x:     pass def x.new_method(self):     pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 From noreply@sourceforge.net Mon Nov 4 10:34:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 02:34:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-633182 ] Memory leak with weakref Message-ID: Bugs item #633182, was opened at 2002-11-04 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633182&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Deleted Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak with weakref Initial Comment: With Python 2.2.2 on Windows 2000, this code leaks 52 bytes of memory for each instance of class foo. <> import weakref, sys class foo: def __init__(self): self.wref = weakref.WeakValueDictionary() self.wref[id(self)] = self l = [foo() for x in range(int(sys.argv[1]))] for i in l: i.wref.clear() del i.wref del l import gc gc.collect() <> These reports are printed by msvc's _CrtMemDumpStatistics() function. C:\>python_d a.py 200 Adding parser accelerators ... Done. [4504 refs] 0 bytes in 0 Free Blocks. 85405 bytes in 1002 Normal Blocks. 4528 bytes in 15 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 556766 bytes. Total allocations: 1300386 bytes. C:\>python_d a.py 300 Adding parser accelerators ... Done. [4504 refs] 0 bytes in 0 Free Blocks. 95805 bytes in 1202 Normal Blocks. 4528 bytes in 15 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 635950 bytes. Total allocations: 1401070 bytes. Current cvs version of Python doesn't leak (with or without PyMalloc). ---------------------------------------------------------------------- >Comment By: atsuo ishimoto (ishimoto) Date: 2002-11-04 19:34 Message: Logged In: YES user_id=463672 I found weakref objects are never freed, but pooled for reuse. Sorry for false alarm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633182&group_id=5470 From noreply@sourceforge.net Mon Nov 4 10:45:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 02:45:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Eddy De Greef (edg) Date: 2002-11-04 11:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 10:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Mon Nov 4 11:04:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 03:04:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 09:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 12:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Mon Nov 4 13:20:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 05:20:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-630195 ] bdist_rpm target breaks with rpm 4.1 Message-ID: Bugs item #630195, was opened at 2002-10-28 19:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630195&group_id=5470 Category: Distutils Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Malcolm Tredinnick (malcolmt) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm target breaks with rpm 4.1 Initial Comment: In order to make the bdist_rpm target in distutils work with a broader range of rpm versions, it is necessary to use the 'rpmbuild' command, rather than 'rpm' to build rpms. Using 'rpm -ba ...' has been deprecated for a couple of years and is no longer part of rpm 4.1 (which is distributed by default with Red Hat 8.0 a.o.). The attached patch fixes this. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:20 Message: Logged In: YES user_id=11375 Fixed in CVS by Sean Reifschneider; his patch is safer, using rpmbuild if present and falling back to rpm. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630195&group_id=5470 From noreply@sourceforge.net Mon Nov 4 13:28:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 05:28:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-570655 ] bdist_rpm and the changelog option Message-ID: Bugs item #570655, was opened at 2002-06-18 12:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) >Assigned to: A.M. Kuchling (akuchling) Summary: bdist_rpm and the changelog option Initial Comment: I think the changelog option for bdist_rpm is not correctly handled. The documentation says it should expect a path to a file containing the changelog entries, but in bdist_rpm.py, line 200, it tries to read it as a string (ensure_string etc). The changelogs are multiple lines, and I was unable to add multi-lined entries in setup.cfg. Even so, the documentation is still misleading. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:28 Message: Logged In: YES user_id=11375 Hmm... looking at old versions of bdist_rpm, changelog has always been a string. We can't change it to a path now because that might break existing setup.py file; instead, the documentation should be fixed. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-28 15:57 Message: Logged In: YES user_id=205865 Uploaded a patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 From noreply@sourceforge.net Mon Nov 4 13:36:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 05:36:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-570655 ] bdist_rpm and the changelog option Message-ID: Bugs item #570655, was opened at 2002-06-18 12:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: A.M. Kuchling (akuchling) Summary: bdist_rpm and the changelog option Initial Comment: I think the changelog option for bdist_rpm is not correctly handled. The documentation says it should expect a path to a file containing the changelog entries, but in bdist_rpm.py, line 200, it tries to read it as a string (ensure_string etc). The changelogs are multiple lines, and I was unable to add multi-lined entries in setup.cfg. Even so, the documentation is still misleading. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:36 Message: Logged In: YES user_id=11375 Option hint fixed in revision 1.33 of bdist_rpm.py; fix also backported to 2.2 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:28 Message: Logged In: YES user_id=11375 Hmm... looking at old versions of bdist_rpm, changelog has always been a string. We can't change it to a path now because that might break existing setup.py file; instead, the documentation should be fixed. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-28 15:57 Message: Logged In: YES user_id=205865 Uploaded a patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 From noreply@sourceforge.net Mon Nov 4 13:54:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 05:54:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-233259 ] Ugly traceback for DistutilsPlatformError Message-ID: Bugs item #233259, was opened at 2001-02-20 11:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Michael Hudson (mwh) Summary: Ugly traceback for DistutilsPlatformError Initial Comment: >From Chad Lester: > I was setting up a new redhat machine, and had forgotten to install the > python-devel rpm. The distutils provide a fairly ugly stack trace / error > message. Luckily, it meant something to me... but it's not terribly user > friendly! > > ... > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 368, in get_config_vars > func() > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 280, in _init_posix > raise DistutilsPlatformError, my_msg > distutils.errors.DistutilsPlatformError: invalid Python > installation: unable to open /usr/lib/python1.5/config/Makefile (No such > file or directory) > > ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:54 Message: Logged In: YES user_id=11375 A simple fix is in the attached patch; it simply adds DistutilsPlatformError to the list of the exception classes caught by core.setup(). However, maybe that exception handler should catch DistutilsError, instead of listing a few particular subclasses of it. Some subclasses represent internal errors or a bad setup file, but as users can always get the full traceback by setting the DISTUTILS_DEBUG environment variable, there seems little need to ever show the full traceback by default. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 11:18 Message: Logged In: YES user_id=11375 Greg, I don't understand your last comment on this bug. Surely the traceback will still be ugly for people running Python 2.2 or whatever who don't have the python-devel RPM installed? I don't see how this is only a 1.5.2 or a "installing Distutils" question. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-02-20 11:24 Message: This only applies for people installing Distutils under Python 1.5.2, so it will only be fixed if there is another Distutils release to support 1.5.2 -- which is unlikely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 From noreply@sourceforge.net Mon Nov 4 13:58:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 05:58:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-466200 ] ability to specify a 'verify' script Message-ID: Bugs item #466200, was opened at 2001-09-28 17:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: A.M. Kuchling (akuchling) Summary: ability to specify a 'verify' script Initial Comment: The following patch adds the ability to specify a 'verify' script (as used by the %verify). Treatment is exactly the same as with post_install, etc... --- bdist_rpm.py Wed Sep 12 11:42:17 2001 +++ /home/agamemnon/jnelson/bdist_rpm.py Fri Sep 28 16:09:18 2001 @@ -131,6 +131,7 @@ self.post_install = None self.pre_uninstall = None self.post_uninstall = None + self.verifyscript = None self.prep = None self.provides = None self.requires = None @@ -210,6 +211,7 @@ self.ensure_filename('post_install') self.ensure_filename('pre_uninstall') self.ensure_filename('post_uninstall') + self.ensure_filename('verifyscript') # XXX don't forget we punted on summaries and descriptions -- they # should be handled here eventually! @@ -423,6 +425,7 @@ ('post', 'post_install', None), ('preun', 'pre_uninstall', None), ('postun', 'post_uninstall', None), + ('verify', 'verifyscript', None), ] for (rpm_opt, attr, default) in script_options: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 From noreply@sourceforge.net Mon Nov 4 14:08:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 06:08:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-459705 ] always return 0 command status Message-ID: Bugs item #459705, was opened at 2001-09-07 21:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=459705&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: always return 0 command status Initial Comment: Context: Python 2.1.1 Description: Python's setup.py build script always return 0 status, without regard to failures. Looking more closely at the problem, it seems that the function distutils.core.setup() has no means of effectively returning to the caller its execution status, and no exception is raised when an extension fails to build. This prevents integration of setup.py programs in scripts (ksh...) or Makefiles which rely on testing the command exit status... ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 09:08 Message: Logged In: YES user_id=11375 As of revision 1.48 of core.py, setup() will now raise the SystemExit exception with a message; this will result in the script returning an exit status of 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=459705&group_id=5470 From noreply@sourceforge.net Mon Nov 4 14:29:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 06:29:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-620630 ] distutils mixed stdin/stdout output Message-ID: Bugs item #620630, was opened at 2002-10-09 02:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: distutils mixed stdin/stdout output Initial Comment: If distutils output is piped to a common logfile, the output is garbled as shown in: http://buildd.debian.org/fetch.php?&pkg=python-numeric&ver=22.0-2&arch=powerpc&stamp=1034115818&file=log&as=raw It's a bit confusing to search errors in the garbled output. It would be nice, if distutils flashes the output buffers on each newline. Not sure how well this shows in the included snippets. gcc-3.2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFSrc/ranlibmodule.c: In function `get_continuous_random': [here in the middle of the line] Src/ranlibmodule.c:47: warning: function declaration isn't a prototype Src/lapack_litemodule.c:649: warning: `lapack_liteError' defined but not used [upto here a compile command, then two other commands succeed, then the error for the link command] /usr/bin/ld: cannot find -lg2c-pic collect2: ld returned 1 exit status [and now the link command:] gcc-3.2 -shared build/temp.linux-ppc-2.3/lapack_litemodule.o -llapack -lblas -lg2c-pic -o build/lib.linux-ppc-2.3/lapack_lite.so error: command 'gcc-3.2' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 09:29 Message: Logged In: YES user_id=11375 Attached is an example of bad output, producing by compiling Numeric with "python setup.py build >out 2>&1". The compiler error messages come first, followed by the distutils 'Building multiarray extension' message. Jeremy's logging reorganization makes a fix simple; just add sys.stdout.flush() to Log._log() in distutils/log.py. Checked in as revision 1.2 of log.py. Matthis, does that fix your problem? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:51 Message: Logged In: YES user_id=6380 The only way to turn on unbuffered output is to use python -u... I can't interpret the output you quote above; and the word "ranlibmodule.c" doesn't occur on the URL you mention; so I'm not sure what the relationship between the two is. I know very little of distutils. It seems it uses spawn() to run subcommands, which uses fork+exec. The buffering set by distutils for itself doesn't affect the buffering of the subcommands. Perhaps you could suggest a patch? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-12 03:44 Message: Logged In: YES user_id=60903 Sure, but then I'll have to change the packaging of about 100 python packages for Debian. The distutils docs talk about "python setup.py", not "python -u setup.py". Can distutils turn on unbuffered output by default? Is there a real performance penalty using distutils with unbuffered output? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 12:16 Message: Logged In: YES user_id=31392 If you're piping the output to a combined log file, you can use python -u to unbuffer stdout. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 From noreply@sourceforge.net Mon Nov 4 16:51:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 08:51:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-610299 ] unicode alphanumeric regexp bug Message-ID: Bugs item #610299, was opened at 2002-09-16 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610299&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Florent Guillaume (efge) Assigned to: Fredrik Lundh (effbot) Summary: unicode alphanumeric regexp bug Initial Comment: I've got the following problem, in python 2.1, 2.2 and 2.3a0 (Debian): >>> import re >>> re.compile(r'\w+', re.U).sub('X', u'hello caf\xe9') u'X X' >>> re.compile(r'\w{1}', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXXX' >>> re.compile(r'\w', re.U).sub('X', u'hello caf\xe9') u'XXXXX XXX\xe9' The first two results are ok, but the third is not. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-11-04 07:51 Message: Logged In: YES user_id=86307 I just posted a small patch to sre_compile.py which should fix this: http://sourceforge.net/tracker/? func=detail&aid=633359&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610299&group_id=5470 From noreply@sourceforge.net Mon Nov 4 17:05:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 09:05:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-625823 ] missing names in telnetlib.py Message-ID: Bugs item #625823, was opened at 2002-10-20 01:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing names in telnetlib.py Initial Comment: The telnet RFC (854 -- http://www.faqs.org/rfcs/rfc854.html) details eleven constants for the telnet protocol that are not included in the telnetlib module. The attached patch adds them. ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2002-11-04 12:05 Message: Logged In: YES user_id=366566 I used the abbreviations the RFC uses. For example, from the RFC: Abort Output (AO) Allow the current process to (appear to) run to completion, but do not send its output to the user. Also, send a Synch to the user. and Erase Line 248 The function EL. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 04:11 Message: Logged In: YES user_id=21627 How did you come up with the symbolic names for these constants? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 From noreply@sourceforge.net Mon Nov 4 18:02:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 10:02:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails Message-ID: Bugs item #543244, was opened at 2002-04-12 14:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470 Category: Installation Group: Python 2.1.2 >Status: Closed Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Jason Tishler (jlt63) Summary: installation atop 2.2 fails Initial Comment: Installing Python 2.2.1 atop Python 2.2 on cygwin fails at the last stage when it tries to create a link from /usr/bin/python.exe -> /usr/bin/python- 2.2.exe. Since the link already exists, installation stops. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-11-04 09:02 Message: Logged In: YES user_id=86216 AFAICT, this is not (or longer) a problem because Python's Makefile removes the symlink if it exists from a previous make install. Hence, I'm closing this bug report. Feel free to reopen if you have evidence indicating that this problem stills exists. See the following for the details: $ make prefix=/tmp/python/usr bininstall /usr/bin/install -c python.exe /tmp/python/usr/bin/python2.2.exe if test -f libpython2.2.so; then \ /usr/bin/install -c -m 644 libpython2.2.so /tmp/python/usr/lib; \ else true; \ fi if test -f "libpython2.2.dll"; then \ /usr/bin/install -c -m 555 libpython2.2.dll /tmp/python/usr/bin; \ else true; \ fi if test -f /tmp/python/usr/bin/python.exe; \ then rm -f /tmp/python/usr/bin/python.exe; \ else true; \ fi (cd /tmp/python/usr/bin; ln -s python2.2.exe python.exe) $ ls -l --full-time /tmp/python/usr/bin total 2561 -r-xr-xr-x 1 jt Domain U 2580813 Mon Nov 04 12:55:35 2002 libpython2.2.dll lrwxrwxrwx 1 jt Domain U 106 Mon Nov 04 12:55:35 2002 python.exe -> python2.2.exe -rwxr-xr-x 1 jt Domain U 40960 Mon Nov 04 12:55:35 2002 python2.2.exe $ make prefix=/tmp/python/usr bininstall /usr/bin/install -c python.exe /tmp/python/usr/bin/python2.2.exe if test -f libpython2.2.so; then \ /usr/bin/install -c -m 644 libpython2.2.so /tmp/python/usr/lib; \ else true; \ fi if test -f "libpython2.2.dll"; then \ /usr/bin/install -c -m 555 libpython2.2.dll /tmp/python/usr/bin; \ else true; \ fi if test -f /tmp/python/usr/bin/python.exe; \ then rm -f /tmp/python/usr/bin/python.exe; \ else true; \ fi (cd /tmp/python/usr/bin; ln -s python2.2.exe python.exe) $ ls -l --full-time /tmp/python/usr/bin total 2561 -r-xr-xr-x 1 jt Domain U 2580813 Mon Nov 04 12:56:31 2002 libpython2.2.dll lrwxrwxrwx 1 jt Domain U 106 Mon Nov 04 12:56:31 2002 python.exe -> python2.2.exe -rwxr-xr-x 1 jt Domain U 40960 Mon Nov 04 12:56:31 2002 python2.2.exe ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 18:23 Message: Logged In: YES user_id=33168 David, Jason, is this still a problem? Can this be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-15 13:22 Message: Logged In: YES user_id=21627 The ln I quoted was actually from a Linux 'make install'; I cannot reproduce the cygwin install since I don't have cygwin - but it *should* only differ in the BINDIR. Since there is only one ln invocation in the makefile, it is hard to believe that 'make install' tries to create a link in the reverse direction. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-04-14 16:31 Message: Logged In: YES user_id=52572 No, it's not that ln. Read my report again. It's linking /usr/bin/python -> /usr/bin/python2.2.exe. No "local" in the path. Since I've already installed 2.2.1, I can't reproduce the behavior anymore without building myself a fresh 2.2... but it happened twice, once on a pydebug installation of 2.2.1 over 2.2 and once on a regular build. -Dave ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-13 15:13 Message: Logged In: YES user_id=21627 Can you report the precise sequence of commands being executed? Normally, it should be if test -f /usr/local/bin/python; \ then rm -f /usr/local/bin/python; \ else true; \ fi (cd /usr/local/bin; ln python2.2 python) If this is the ln that fails, it is not clear why the target already exists: the rm command is supposed to delete it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-12 15:09 Message: Logged In: YES user_id=31435 Change Group to Platform-specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470 From noreply@sourceforge.net Mon Nov 4 17:41:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 09:41:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-625823 ] missing names in telnetlib.py Message-ID: Bugs item #625823, was opened at 2002-10-20 07:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing names in telnetlib.py Initial Comment: The telnet RFC (854 -- http://www.faqs.org/rfcs/rfc854.html) details eleven constants for the telnet protocol that are not included in the telnetlib module. The attached patch adds them. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 18:41 Message: Logged In: YES user_id=21627 Thanks for the elaboration. I have applied this patch as telnetlib.py 1.21, libtelnetlib.tex 1.11. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2002-11-04 18:05 Message: Logged In: YES user_id=366566 I used the abbreviations the RFC uses. For example, from the RFC: Abort Output (AO) Allow the current process to (appear to) run to completion, but do not send its output to the user. Also, send a Synch to the user. and Erase Line 248 The function EL. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 10:11 Message: Logged In: YES user_id=21627 How did you come up with the symbolic names for these constants? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 From noreply@sourceforge.net Mon Nov 4 18:12:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 10:12:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown Message-ID: Bugs item #231207, was opened at 2001-02-05 19:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Henderson (djhender) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python Error during program shutdown Initial Comment: The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a event or call to a ?.destory() function. Under Windows 98SE, this results in a GPF. Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate". The following script demonstrates the problem: --------------------- # BugDemo.py from Tkinter import * class BugDemo(Frame): def __init__(self, parent): Frame.__init__(self, parent) Button(self, text='Hi', command=self.hi).pack() Button(self, text='Quit', command=self.tk.quit).pack() def hi(self): print "hi" bd = BugDemo(Tk()) bd.pack() bd.mainloop() ---------------------- Execute in console window: "c:> python BugDemo.py" Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button. Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly. Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time. The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem. Problem also manifests using the PythonWare 2.0 release on Win98. ---------------------------------------------------------------------- >Comment By: Doug Henderson (djhender) Date: 2002-11-04 11:12 Message: Logged In: YES user_id=148444 I modified my BugDemo program to change the last 3 lines to root = Tk() bd = BugDemo(root) bd.pack() bd.mainloop() root.destory() This did not resolve the problem under Win98SE Python 2.2.1. Both Python 2.2.1 and 2.2.2 use Tk/tcl 8.3. I have seen comments that indicate that this is a known problem in stock 8.3 which is fixed in 8.4. I also tested using the other two scripts presented elsewhere among the comments to this bug report. These tests also hang, even with the added root.destroy() statement. I no longer have access to a Win2k machine, so I cannot test there. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 23:52 Message: Logged In: YES user_id=33229 I know I'm a Python newbie but I know Tcl well and I think I know at least part of what's going on. Looking specifically at nobody's 2002-04-22 14:21 code, I see that this uses mainloop and quit in a way that many Python books and examples do, as if quit() will "Quit the Tcl interpreter. All widgets will be destroyed." But if you look at MainLoop and Quit in _tkinter.c you see that Quit just sets a variable that causes MainLoop to end - it doesn't destroy anything nor quit the interpreter. IMHO all Tkinter programs need a root.destroy() after root.mainloop() If you change nobody's program to add a root.destroy() it runs fine under PythonWin. The "bug" is in the documentation of quit() in Tkinter.py def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self.tk.quit() The comment should read """Quit the main event loop. It is up to you to call root.destroy() after.""" If I'm right the documentation for Tkinter in the library reference should be changed too; there should be a root.destroy() at the end of http://www.python.org/doc/2.2.1/lib/node503.html If I'm right then I'll stick my neck out a little further: Tkinter's mainloop and quit should be dropped from _tkinter.c and replaced with the following idiom and usage: In Tkinter.py declare a class variable in Misc: _exit = -1 and change in Misc TCL_ALL_EVENTS = 0 def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self._exit = 0 def mainloop(self): """Loop until we call quit()""" while self._exit < 0: try: self.root.tk.dooneevent(TCL_ALL_EVENTS) except SystemExit: #print 'Exit' self.exit = 1 break except # do something intelligent with errors or interrupts I believe this is more transparent and more open to creativity. I have experimented (all my code is like this now) and feel that there is no performance penalty to looping in Python. In addition it avoids the 20msec sleep in _tkinter.mainloop() that is an abomination. It would also allow people to think more clearly about what happens when you have 2 Tk() instances, in which case you have 2 Tcl interpeters. It may make you move _exit to be an instance variable of the Tk class. In any event you'll be able to see what's going on. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 08:21 Message: Logged In: NO I confirm the behaviour for: WinNT 4.0 SP5 tested with Python 2.2Beta1 (ActiveState) tested with Python 2.2.1.222 (ActiveState) PythonWinIDE will hang when the following program is "quit"ted. But will "quit" normally when run standalone (not within PythonWinIDE): # # from Tkinter import * from tkMessageBox import * class App: def __init__(self, winRoot): frame = Frame(winRoot) frame.pack() self.btnQuit = Button(frame, text="QUIT", bg="blue", foreground="light blue", command=frame.quit) self.btnQuit.pack(side=LEFT) self.btnHiThere = Button(frame, text="Hi there!",command=self.sayHiThere) self.btnHiThere.pack(side=LEFT) def sayHiThere(self): showinfo("Greeting", "Hi There") if __name__ == "__main__": root = Tk() test = App(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 15:49 Message: Logged In: YES user_id=31392 Unassign as it appears that effbot isn't going to look at it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-18 05:13 Message: Logged In: NO i won't to be a hacker ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-29 01:30 Message: Logged In: NO Note: I am running Windows98 ActivePython 2.1 Even with console apps in python this same error appears I tried using another Distribution of Python for win32, PythonWare20 So this leads me to believe that some lib is missing on win98. Because at work I use Win95, and Installed ActivePython 2.1, and it works fine and dandy ---------------------------------------------------------------------- Comment By: Joel Gould (joelgould) Date: 2001-03-24 09:52 Message: Logged In: YES user_id=20954 I also see a GPF on shutdown under Windows 98 using Tkinter. I tested this using the PythonWare 2.0 release as well. I have attached a very simple Tkinter program. When I run this on my Windows 98 SE machine, a crash occurs when the program exits. Without the MainDialog class it works OK. Without the Pmw initialization call it works OK. But as written it will crash around 75% of the time. (1) run the program (2) press the Test Button (3) click Cancel in the file open dialog (you do not need to select a file) (4) click the close button in the upper right corner --> Boom -------------------- import Tkinter import tkFileDialog import Pmw def action(): tkFileDialog.askopenfilename(filetypes=[('All','*')]) class MainDialog: def __init__(self,parent): Tkinter.Button(parent,text='Test Button',command=action).pack() root = Pmw.initialise() dialog = MainDialog(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-09 16:34 Message: Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-05 22:30 Message: See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 From noreply@sourceforge.net Mon Nov 4 20:36:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 12:36:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-04 21:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 10:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 23:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Mon Nov 4 20:37:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 12:37:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips Message-ID: Bugs item #410541, was opened at 2001-03-22 17:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: Nobody/Anonymous (nobody) Summary: bdist builds bogus .zips Initial Comment: According to Thomas Heller: "... the resulting zip-file from 'bdist --formats=zip' is unusable because it contains filenames relative to the root directory)" Such paths may be OK for Unix (cd / and unzip it, perhaps?), but isn't much good for Windows, where Python might be installed anywhere. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 16:29 Message: Logged In: YES user_id=11105 Yes. We would have to remove everything except 'rpm' and 'wininst' from bdist's available formats lists. But it seems the right way to do. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-26 15:52 Message: Logged In: YES user_id=11375 Why not just remove bdist_dumb, then? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 15:07 Message: Logged In: YES user_id=11105 IMO it is impossible to create a dumb binary distribution which can be used to install a package - even on the same platform for different Python versions. So it seems the only possibility is document dumb binary distros as broken. The DISTUTILS TODO list is mainly just a list of thoughts from the previous maintainer, nobody (so far) is caring too much about it currently. Assigning to AMK: Andrew, if you think this is ok, let us close this bug. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-03-06 21:33 Message: Logged In: YES user_id=149084 I'm not sure what is meant by "everyone should install from source or the native binary for his platform." My understanding is that Distutils was created to provide a uniform way to install third party packages. It seems that bdist_dumb has problems building a package distribution which will install properly. What about non-Linux or Windows systems? It rather looks like the code is unfinished.... To quote the TODO (DISTUTILS 1.1 PLANS): "* bdist_dumb should grow a little intelligence: let packager choose whether to make archive relative to prefix or the root (prefix is essential for proper Windows support )" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-05 22:08 Message: Logged In: YES user_id=11105 I expect nobody will install from a zip-file on windows, either. I suggest making bdist_wininst the default bdist format on windows and forget this one: Everyone should (will?) install either from source, or from the native binary distribution for his platform. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 23:54 Message: Logged In: YES user_id=31392 Can you look at this one, Thomas? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-28 00:33 Message: Logged In: YES user_id=149084 gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.) The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do? It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages. Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user. GvR seems to be interested in making the install trees the same on Linux and Windows, that would help. Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist? If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 22:39 Message: Logged In: YES user_id=11375 I expect no one will install from a .zip file on Unix. Options: 1) Make both the .tgz and .zip relative to sys.prefix or something. 2) Make only the .zip relative. 3) Document this as being broken and forget about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 From noreply@sourceforge.net Mon Nov 4 20:58:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 12:58:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 15:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 15:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Mon Nov 4 21:06:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 13:06:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-633480 ] IOError w/ large string to CMD shell Message-ID: Bugs item #633480, was opened at 2002-11-04 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Tim Peters (tim_one) Summary: IOError w/ large string to CMD shell Initial Comment: If I try to run this program with "python2.2.1 -u": # 61409 works!! print ' ' * 61410 (which tries to print a string of 61,410 space characters), I get this Traceback on Windows 2000 SP2: Traceback (most recent call last): File "write.py", line 4, in ? print ' ' * 61410 IOError: [Errno 12] Not enough space Without "-u", this runs fine, and if I change "print" to "import sys; sys.stdout.write" instead, it still fails. I think this is happening in Objects/fileobject.c -- the calls to fwrite apparently don't write all bytes in win32 when the number of bytes is large -- seems like it may be necessary to parcel the data up into smaller pieces or something? NOTE: it's possible that the exact length of the string that fails may be larger on other OS's... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 From noreply@sourceforge.net Mon Nov 4 21:34:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 13:34:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-633480 ] IOError w/ large string to CMD shell Message-ID: Bugs item #633480, was opened at 2002-11-04 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None >Priority: 4 Submitted By: Michael McCandless (mikemccand) >Assigned to: Nobody/Anonymous (nobody) Summary: IOError w/ large string to CMD shell Initial Comment: If I try to run this program with "python2.2.1 -u": # 61409 works!! print ' ' * 61410 (which tries to print a string of 61,410 space characters), I get this Traceback on Windows 2000 SP2: Traceback (most recent call last): File "write.py", line 4, in ? print ' ' * 61410 IOError: [Errno 12] Not enough space Without "-u", this runs fine, and if I change "print" to "import sys; sys.stdout.write" instead, it still fails. I think this is happening in Objects/fileobject.c -- the calls to fwrite apparently don't write all bytes in win32 when the number of bytes is large -- seems like it may be necessary to parcel the data up into smaller pieces or something? NOTE: it's possible that the exact length of the string that fails may be larger on other OS's... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-04 16:34 Message: Logged In: YES user_id=31435 Couldn't reproduce under Win98SE and 2.2.2 even boosting the size to a million. It *may* have to do with console-size settings under cmd.exe. Reduced the priority. "So don't do that" comes to mind . Seriously, if the platform C fwrite chokes, it's not Python's job to fix it -- it's Microsoft's. The interpreter isn't dying here, it's raising a well-behaved exception, just passing on the error the platform fwrite() raised. To me it's the same as the system malloc complaining that you don't have enough memory to satisfy a request: you've exceeded a platform limitation. If this is important to you, you can presumably fix it yourself by chunking up your writes in a loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 From noreply@sourceforge.net Mon Nov 4 21:51:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 13:51:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-633504 ] cgi.py drops commandline arguments Message-ID: Bugs item #633504, was opened at 2002-11-04 21:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633504&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Randall Randall (randallrandall) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py drops commandline arguments Initial Comment: Keyword arguments in URLs are currently ignored by the cgi.parse_qsl() function, even though they are explicitly included by cgi.parse(), i.e.: 
...
    elif sys.argv[1:]:
        if qs: qs = qs + '&'
        qs = qs + sys.argv[1]
...
A simple patch to fix this follows: 
216c216
<             continue
---
>             else: nv.append('')
This fix doesn't affect those using strictparsing=1 , which will still fail to include anything without an equals ('='). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633504&group_id=5470 From noreply@sourceforge.net Mon Nov 4 22:57:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 14:57:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-04 17:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 15:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 15:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:07:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:07:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-633527 ] HeaderParseError: no newline Message-ID: Bugs item #633527, was opened at 2002-11-04 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: HeaderParseError: no newline Initial Comment: This is for email 2.4.3. When trying to parse a message which lacks a newline separating the header and body, email throws a HeaderParseError: email.Errors.HeaderParseError: Not a header, not a continuation: ``foobar.'' However, the rfc822 package is able to correctly parse such a message into separate header and body portions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:08:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:08:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-633527 ] HeaderParseError: no newline Message-ID: Bugs item #633527, was opened at 2002-11-04 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: HeaderParseError: no newline Initial Comment: This is for email 2.4.3. When trying to parse a message which lacks a newline separating the header and body, email throws a HeaderParseError: email.Errors.HeaderParseError: Not a header, not a continuation: ``foobar.'' However, the rfc822 package is able to correctly parse such a message into separate header and body portions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:10:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:10:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-633527 ] HeaderParseError: no newline Message-ID: Bugs item #633527, was opened at 2002-11-04 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: HeaderParseError: no newline Initial Comment: This is for email 2.4.3. When trying to parse a message which lacks a newline separating the header and body, email throws a HeaderParseError: email.Errors.HeaderParseError: Not a header, not a continuation: ``foobar.'' However, the rfc822 package is able to correctly parse such a message into separate header and body portions. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-04 16:10 Message: Logged In: YES user_id=85984 Also see the following more on this problem: http://article.gmane.org/gmane.mail.spam.tmda.user/7007 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:36:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:36:53 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-633543 ] Korean support, unknown charsets Message-ID: Feature Requests item #633543, was opened at 2002-11-04 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: Korean support, unknown charsets Initial Comment: The following patch needs to be integrated into the email package: http://article.gmane.org/gmane.comp.python.mime.devel/250 Most of it was delayed due to the impending Python 2.2.2 release, but the patch is important, and I don't want to see the work lost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:37:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:37:24 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-633543 ] Korean support, unknown charsets Message-ID: Feature Requests item #633543, was opened at 2002-11-04 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Korean support, unknown charsets Initial Comment: The following patch needs to be integrated into the email package: http://article.gmane.org/gmane.comp.python.mime.devel/250 Most of it was delayed due to the impending Python 2.2.2 release, but the patch is important, and I don't want to see the work lost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:55:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:55:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-633550 ] HeaderParseError: no header value Message-ID: Bugs item #633550, was opened at 2002-11-04 16:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633550&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: HeaderParseError: no header value Initial Comment: We all know according to rfc 2822, that a header field should be composed of name: value, but sometimes (as in the case of SPAM), this is not the case. In email 2.4.3, if a header field lacks a value portion a HeaderParseError is raised. For an example message and traceback, see http://article.gmane.org/gmane.comp.python.mime.devel/325 I think when strict parsing is turned on, this behavior is fine, but not when it's turned off. In lax parsing mode, I don't think this should raise an exception. Perhaps just skipping the bogus header field is acceptable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633550&group_id=5470 From noreply@sourceforge.net Mon Nov 4 23:55:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 15:55:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-633550 ] HeaderParseError: no header value Message-ID: Bugs item #633550, was opened at 2002-11-04 16:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633550&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: HeaderParseError: no header value Initial Comment: We all know according to rfc 2822, that a header field should be composed of name: value, but sometimes (as in the case of SPAM), this is not the case. In email 2.4.3, if a header field lacks a value portion a HeaderParseError is raised. For an example message and traceback, see http://article.gmane.org/gmane.comp.python.mime.devel/325 I think when strict parsing is turned on, this behavior is fine, but not when it's turned off. In lax parsing mode, I don't think this should raise an exception. Perhaps just skipping the bogus header field is acceptable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633550&group_id=5470 From noreply@sourceforge.net Tue Nov 5 00:29:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 16:29:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-633560 ] tokenize.__all__ needs "generate_tokens" Message-ID: Bugs item #633560, was opened at 2002-11-04 18:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633560&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: tokenize.__all__ needs "generate_tokens" Initial Comment: The tokenize module needs to have its __all__ attribute updated, like such: __all__ = [x for x in dir(token) if x[0] != '_'] + ["COMMENT", "tokenize", "NL", "generate_tokens"] The current version is missing "generate_tokens": __all__ = [x for x in dir(token) if x[0] != '_'] + ["COMMENT", "tokenize", "NL"] While "tokenize" is described as an "older entry point", it appears to still be useful and is certainly used when tokenize is run from the command line. So I'm not sure what the intent is for describing it in those terms, since it doesn't appear that the intent is to deprecate the tokenize function. Pat (looking for love in __all__ the wrong places) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633560&group_id=5470 From noreply@sourceforge.net Tue Nov 5 01:30:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 17:30:46 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-618024 ] urlparse fails on imap:// Message-ID: Feature Requests item #618024, was opened at 2002-10-03 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Asle Pedersen (apederse) >Assigned to: Piers Lauder (pierslauder) Summary: urlparse fails on imap:// Initial Comment: urlparse does not parse imap:// urls (RFC 2192). I am not all sure but this seem to be an appropriate patch: urlparse.uses_relative.append('imap') urlparse.uses_netloc.append('imap') urlparse.non_hierarchical.append('imap') urlparse.uses_params.append('imap') urlparse.uses_query.append('imap') ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 20:30 Message: Logged In: YES user_id=33168 Piers, is this right? If so, I can make the change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 From noreply@sourceforge.net Tue Nov 5 02:03:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 18:03:22 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-494240 ] str.reverse Message-ID: Feature Requests item #494240, was opened at 2001-12-17 11:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: str.reverse Initial Comment: The str type should *really* have a reverse method. "How do I reverse a string?" crops up too often on tutor lists, and there should be a neater way to do it other than converting it to a list, reversing it, and then joining it... ---------------------------------------------------------------------- Comment By: michael morrell (mgmorrell) Date: 2002-11-04 21:03 Message: Logged In: YES user_id=642473 A real life example certainly does exist. A source text file from the "Online Bible" Hebrew text files are in ascii, but, are backwards on each line, for purpose such as sorting etc. They need to be reversed for my purposes, often. and then reversed back. I for one firmly believe you should have a reverse() in python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-30 08:49 Message: Logged In: YES user_id=6380 But reversing a string is such a rare thing to do that it's not worth extending the language for it. ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2002-09-30 04:44 Message: Logged In: YES user_id=39733 > "spam"[::-1] Well, it's nice to be able to reverse a string easily, but does anyone else think that using this syntax to reverse a string is somewhat un-Pythonic? "spam".reverse() would at least make sense instantly to anyone reading it... ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2002-09-30 04:44 Message: Logged In: YES user_id=39733 > "spam"[::-1] Well, it's nice to be able to reverse a string easily, but does anyone else think that using this syntax to reverse a string is somewhat un-Pythonic? "spam".reverse() would at least make sense instantly to anyone reading it... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-04 15:45 Message: Logged In: YES user_id=89016 String reversing is possible now via extended slices: >>> "spam"[::-1] 'maps' I guess we can close the request. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 23:57 Message: Logged In: YES user_id=31435 Here's an application of (sub)string reversal in dartboard design: http://www.combinatorics.org/Volume_8/PDF/v8i2r4.pdf I'd hate to see Python fall behind in the lucrative dartboard designer market . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 23:22 Message: Logged In: YES user_id=6380 Write a PEP. :-) ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2001-12-17 23:17 Message: Logged In: YES user_id=39733 > Show me one real-life application of reversing a string. Ummm.... easy way to check for palindromes? > This comes from textbook exercises IMO, > and doesn't occur in real life. It may not occur in many serious applications, but there have been occasions where I've simply wanted to reverse a string just for the fun of it really (or just to check quickly what something is backwards). > Adding the method would reduce the > utility of the textbook exercise... Not unless you explicitly said not to use str.reverse... You could argue that doing l = list('something'); l.reverse (); ''.join(l) perhaps is still a bit too easy for a text book. Something more appropriate like for loops and ranges would be suitable for an exercise. I dunno, it just seems like it's the sort of method that should be part of str, and it doesn't seem like the method would be that huge or problematic to implement... If that doesn't convince you, then at least say you'll implement it if I figure out a worthwhile use for it. :)) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 11:57 Message: Logged In: YES user_id=6380 Show me one real-life application of reversing a string. This comes from textbook exercises IMO, and doesn't occur in real life. Adding the method would reduce the utility of the textbook exercise... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494240&group_id=5470 From noreply@sourceforge.net Tue Nov 5 02:19:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 18:19:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-04 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 02:19 Message: Logged In: YES user_id=7887 I'm attaching a proposed solution. Here is how the magic is done: There's a new CCompiler.detect_language() method, which based on the sources extensions and on language_map and language_order class variables (subclasses can overload these), determine what's the "target language" of a set of source files. This target language is passed to every CCompiler method which deals with the linkage step (create_static_lib(), link(), and link_*()). UnixCCompiler uses this information to replace the linking command (if the target language is c++) with cpp_linker[0], which is set on sysconfig.py:customize_compiler(). Other classes, such as msvccompiler.py, could also use the same infrastructure to remove some of the hardcoded extension tests already there. Additionally, an Extension can set the "language" parameter to hardcode a language in setup.py. (PS. this patch also fixes some wrong prototypes of create_static_libs()) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-18 12:55 Message: Logged In: YES user_id=6380 reassigned to amk who should know ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-18 06:47 Message: Logged In: YES user_id=29957 can this be closed as a duplicate of 454030? That one has a real submitter, and some more info... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-05 00:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Tue Nov 5 06:09:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Nov 2002 22:09:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-633560 ] tokenize.__all__ needs "generate_tokens" Message-ID: Bugs item #633560, was opened at 2002-11-04 19:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633560&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) >Assigned to: Raymond Hettinger (rhettinger) >Summary: tokenize.__all__ needs "generate_tokens" Initial Comment: The tokenize module needs to have its __all__ attribute updated, like such: __all__ = [x for x in dir(token) if x[0] != '_'] + ["COMMENT", "tokenize", "NL", "generate_tokens"] The current version is missing "generate_tokens": __all__ = [x for x in dir(token) if x[0] != '_'] + ["COMMENT", "tokenize", "NL"] While "tokenize" is described as an "older entry point", it appears to still be useful and is certainly used when tokenize is run from the command line. So I'm not sure what the intent is for describing it in those terms, since it doesn't appear that the intent is to deprecate the tokenize function. Pat (looking for love in __all__ the wrong places) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-05 01:09 Message: Logged In: YES user_id=80475 Fixed. See tokenize 1.34 and 1.28.14.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633560&group_id=5470 From noreply@sourceforge.net Tue Nov 5 08:12:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 00:12:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-04 02:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 09:12 Message: Logged In: YES user_id=21627 A couple of comments: - distutils should stay compatible with earlier versions of Python, back to 1.5.2. So don't use isinstance(value, list), as list might be a function - cpp_ might be confused as having to do with the preprocessor; I recommend to use cxx_ throughout - You should check whether CXX is set. If it isn't, and you need to compile a C++ file, you should probably raise an exception. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 03:19 Message: Logged In: YES user_id=7887 I'm attaching a proposed solution. Here is how the magic is done: There's a new CCompiler.detect_language() method, which based on the sources extensions and on language_map and language_order class variables (subclasses can overload these), determine what's the "target language" of a set of source files. This target language is passed to every CCompiler method which deals with the linkage step (create_static_lib(), link(), and link_*()). UnixCCompiler uses this information to replace the linking command (if the target language is c++) with cpp_linker[0], which is set on sysconfig.py:customize_compiler(). Other classes, such as msvccompiler.py, could also use the same infrastructure to remove some of the hardcoded extension tests already there. Additionally, an Extension can set the "language" parameter to hardcode a language in setup.py. (PS. this patch also fixes some wrong prototypes of create_static_libs()) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-18 14:55 Message: Logged In: YES user_id=6380 reassigned to amk who should know ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-18 08:47 Message: Logged In: YES user_id=29957 can this be closed as a duplicate of 454030? That one has a real submitter, and some more info... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 17:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-05 02:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Tue Nov 5 10:44:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 02:44:05 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-618024 ] urlparse fails on imap:// Message-ID: Feature Requests item #618024, was opened at 2002-10-03 21:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Asle Pedersen (apederse) Assigned to: Piers Lauder (pierslauder) Summary: urlparse fails on imap:// Initial Comment: urlparse does not parse imap:// urls (RFC 2192). I am not all sure but this seem to be an appropriate patch: urlparse.uses_relative.append('imap') urlparse.uses_netloc.append('imap') urlparse.non_hierarchical.append('imap') urlparse.uses_params.append('imap') urlparse.uses_query.append('imap') ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2002-11-05 21:44 Message: Logged In: YES user_id=196212 I've never tried to use the imap URL form, and I'm unaware of which IETF RFC documents its allowable syntax. Seems ok, but why not "urlparse.uses_fragment.append('imap')" as well? (Searching google...) This looks like the document that defines it: http://ftp.ics.uci.edu/pub/ietf/uri/rfc2192.txt "IMAP URL Scheme" No mention of '#', so I guess no fragments :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-05 12:30 Message: Logged In: YES user_id=33168 Piers, is this right? If so, I can make the change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 From noreply@sourceforge.net Tue Nov 5 11:16:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 03:16:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-631247 ] Mac OS 10 configure problem Message-ID: Bugs item #631247, was opened at 2002-10-30 22:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631247&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) >Assigned to: Jack Jansen (jackjansen) Summary: Mac OS 10 configure problem Initial Comment: Using the Python CVS head from about two days ago: Under Mac OS 10 configure --enable-framework; make fails if the source directory is on a NFS mounted disk, but the build directory in a case insensitive Mac volume. According to Jack Jansen this is because configure checks if the source directory is on a file system that is case insensitive, when it should be checking the file system with the build directory: if test -d "${srcdir}/python" then echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 BUILDEXEEXT=.exe else echo "$as_me:$LINENO: result: no" >&5 echo "${ECHO_T}no" >&6 BUILDEXEEXT=$EXEEXT fi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631247&group_id=5470 From noreply@sourceforge.net Tue Nov 5 12:42:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 04:42:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-04 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 12:42 Message: Logged In: YES user_id=7887 (I just realized I posted the patch to this bug, and not the one I told. Sorry) Ok.. I'm attaching a new patch including your suggestions. A few comments: - Instead of setting cpp_linker, I'm now using compiler_cxx, as that's what it really is right now, from a Makefile point of view. Other compilers may want to use it in different places. - I'm now checking if compiler_cxx is set before using it. In the worst case, the old behavior will be used, hoping for the best. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 08:12 Message: Logged In: YES user_id=21627 A couple of comments: - distutils should stay compatible with earlier versions of Python, back to 1.5.2. So don't use isinstance(value, list), as list might be a function - cpp_ might be confused as having to do with the preprocessor; I recommend to use cxx_ throughout - You should check whether CXX is set. If it isn't, and you need to compile a C++ file, you should probably raise an exception. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 02:19 Message: Logged In: YES user_id=7887 I'm attaching a proposed solution. Here is how the magic is done: There's a new CCompiler.detect_language() method, which based on the sources extensions and on language_map and language_order class variables (subclasses can overload these), determine what's the "target language" of a set of source files. This target language is passed to every CCompiler method which deals with the linkage step (create_static_lib(), link(), and link_*()). UnixCCompiler uses this information to replace the linking command (if the target language is c++) with cpp_linker[0], which is set on sysconfig.py:customize_compiler(). Other classes, such as msvccompiler.py, could also use the same infrastructure to remove some of the hardcoded extension tests already there. Additionally, an Extension can set the "language" parameter to hardcode a language in setup.py. (PS. this patch also fixes some wrong prototypes of create_static_libs()) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-18 12:55 Message: Logged In: YES user_id=6380 reassigned to amk who should know ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-18 06:47 Message: Logged In: YES user_id=29957 can this be closed as a duplicate of 454030? That one has a real submitter, and some more info... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-05 00:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Tue Nov 5 12:53:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 04:53:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-04 02:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 13:53 Message: Logged In: YES user_id=21627 This patch looks fine, please apply it. If you have spare time, please check out the distutils CVS module, and see whether the tests still pass. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 13:42 Message: Logged In: YES user_id=7887 (I just realized I posted the patch to this bug, and not the one I told. Sorry) Ok.. I'm attaching a new patch including your suggestions. A few comments: - Instead of setting cpp_linker, I'm now using compiler_cxx, as that's what it really is right now, from a Makefile point of view. Other compilers may want to use it in different places. - I'm now checking if compiler_cxx is set before using it. In the worst case, the old behavior will be used, hoping for the best. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 09:12 Message: Logged In: YES user_id=21627 A couple of comments: - distutils should stay compatible with earlier versions of Python, back to 1.5.2. So don't use isinstance(value, list), as list might be a function - cpp_ might be confused as having to do with the preprocessor; I recommend to use cxx_ throughout - You should check whether CXX is set. If it isn't, and you need to compile a C++ file, you should probably raise an exception. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 03:19 Message: Logged In: YES user_id=7887 I'm attaching a proposed solution. Here is how the magic is done: There's a new CCompiler.detect_language() method, which based on the sources extensions and on language_map and language_order class variables (subclasses can overload these), determine what's the "target language" of a set of source files. This target language is passed to every CCompiler method which deals with the linkage step (create_static_lib(), link(), and link_*()). UnixCCompiler uses this information to replace the linking command (if the target language is c++) with cpp_linker[0], which is set on sysconfig.py:customize_compiler(). Other classes, such as msvccompiler.py, could also use the same infrastructure to remove some of the hardcoded extension tests already there. Additionally, an Extension can set the "language" parameter to hardcode a language in setup.py. (PS. this patch also fixes some wrong prototypes of create_static_libs()) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-18 14:55 Message: Logged In: YES user_id=6380 reassigned to amk who should know ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-18 08:47 Message: Logged In: YES user_id=29957 can this be closed as a duplicate of 454030? That one has a real submitter, and some more info... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 17:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-05 02:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Tue Nov 5 12:54:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 04:54:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-630494 ] expat causes a core dump Message-ID: Bugs item #630494, was opened at 2002-10-29 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 Category: XML Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) >Assigned to: Martin v. Löwis (loewis) Summary: expat causes a core dump Initial Comment: Raising an exception inside a StartNamespaceDeclHandler causes python to dump core. The attached program will cause a segmentation fault. Note it is possible to raise exception in the StartElementHandler and EndElementHandler with Python 2.0 >python2.0 expat_testje.py None 123 Segmentation fault (core dumped) with Python 2.2.1 >python2 expat_testje.py None 123 Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-29 23:14 Message: Logged In: YES user_id=33168 This core dumps on 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 From noreply@sourceforge.net Tue Nov 5 13:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 05:29:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-633480 ] IOError w/ large string to CMD shell Message-ID: Bugs item #633480, was opened at 2002-11-04 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 4 Submitted By: Michael McCandless (mikemccand) Assigned to: Nobody/Anonymous (nobody) Summary: IOError w/ large string to CMD shell Initial Comment: If I try to run this program with "python2.2.1 -u": # 61409 works!! print ' ' * 61410 (which tries to print a string of 61,410 space characters), I get this Traceback on Windows 2000 SP2: Traceback (most recent call last): File "write.py", line 4, in ? print ' ' * 61410 IOError: [Errno 12] Not enough space Without "-u", this runs fine, and if I change "print" to "import sys; sys.stdout.write" instead, it still fails. I think this is happening in Objects/fileobject.c -- the calls to fwrite apparently don't write all bytes in win32 when the number of bytes is large -- seems like it may be necessary to parcel the data up into smaller pieces or something? NOTE: it's possible that the exact length of the string that fails may be larger on other OS's... ---------------------------------------------------------------------- >Comment By: Michael McCandless (mikemccand) Date: 2002-11-05 08:29 Message: Logged In: YES user_id=323786 Thanks for looking into this Tim... True, we can workaround it -- either don't run UNBUFFERED, or break up the strings before printing (override sys.stdout w/ our own file object that tries to break things up before printing), or don't run under "CMD" or other platform-specific shells that have this issue. But it's rather unexpected and to a "Python newbie" would be "surprising"; though I suppose most would not run with "- u". Also, from the IOError that's raised I don't know how many bytes were actually successfully written (apparently 0 in this case). NOTE: I'm able to reproduce on Windows XP Professional (no SP), running "cmd.exe", Python 2.2.2. I've also tried changing the "screen buffer" sizes on the CMD and it does not seem to change things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 16:34 Message: Logged In: YES user_id=31435 Couldn't reproduce under Win98SE and 2.2.2 even boosting the size to a million. It *may* have to do with console-size settings under cmd.exe. Reduced the priority. "So don't do that" comes to mind . Seriously, if the platform C fwrite chokes, it's not Python's job to fix it -- it's Microsoft's. The interpreter isn't dying here, it's raising a well-behaved exception, just passing on the error the platform fwrite() raised. To me it's the same as the system malloc complaining that you don't have enough memory to satisfy a request: you've exceeded a platform limitation. If this is important to you, you can presumably fix it yourself by chunking up your writes in a loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 From noreply@sourceforge.net Tue Nov 5 13:42:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 05:42:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-602444 ] non greedy match bug Message-ID: Bugs item #602444, was opened at 2002-08-30 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470 Category: Regular Expressions >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Fredrik Lundh (effbot) Summary: non greedy match bug Initial Comment: When using the following re to extract all objects from a PDF file, I get a maximum recursion limit exceeded error. Attached is a pdf file that will reproduce the error. If I do import pre as re, it works fine. platform is Win2k, Python 2.2.1 build #34 ####### import re GETOBJECT = re.compile(r'\d+\s+\d+\s+obj.+?endobj', re.I|re.S|re.M) pdf = open('userguide.pdf', 'rb').read() all = GETOBJECT.findall(pdf) print len(all) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602444&group_id=5470 From noreply@sourceforge.net Tue Nov 5 15:27:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 07:27:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-633858 ] trouble printing mimelib.pdf Message-ID: Bugs item #633858, was opened at 2002-11-05 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633858&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Grant Griffin (dspguru) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: trouble printing mimelib.pdf Initial Comment: I could not print pages 2, 11, and 24 of the PDF form of "mimelib.pdf", which is the manual for the new email, (BTW, why not rename it to "email.pdf"?) I tried using two different printers from two different manufacturers, and I tried printing from within Internet Explorer as well as from within Acrobat Reader. In each case, I got the message, "The document could not be printed". Other pages printed fine--though printing always stopped at the point of the offending page. (I therefore had print it in segments, less pages 2, 11, and 24.) My guess is that there is something unusual on these pages that is not friendly to printers, oncethe source document gets translated to PDF. (I apologize in advance if this has previously reported and/or is a cockpit error on my part--as my bug reports usually are .) thanks, =g2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633858&group_id=5470 From noreply@sourceforge.net Tue Nov 5 16:15:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 08:15:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions Message-ID: Bugs item #413582, was opened at 2001-04-04 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 Category: Distutils Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Gustavo Niemeyer (niemeyer) Summary: g++ must be called for c++ extensions Initial Comment: When building c++ extension using distutils setup, the compiler that was used to build python distribution is always called. On Linux, it is normally gcc. When gcc is called to link shared library, it does not link certain c++ runtime stuff. As a result, when extension is imported, missing symbols are reported, e.g.: >>> import ex_ext1 Traceback (most recent call last): File "", line 1, in ? ImportError: ./ex_ext1.so: undefined symbol: __vt_13runtime_error >>> I tried to use "extra_link_args = ['-x c++']" in setup.py (it tells gcc to link as c++), but that gets added to the end of compiler's command line, which results in: gcc -shared build/temp.linux-i686-2.1/ex_ext1.o -L../boost/libs/python -lboost_python -o build/lib.linux-i686-2.1/ex_ext1.so -x c++ gcc: Warning: `-x c++' after last input file has no effect Proposed solution: either use CXX= variable from Python Makefile when c++ files are involved, or prepend extra_link_args to compiler's arguments instead of appending them. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 16:15 Message: Logged In: YES user_id=7887 Applied as: bcppcompiler.py:1.13->1.14 ccompiler.py:1.49->1.50 cygwinccompiler.py:1.18->1.19 emxccompiler.py:1.8->1.9 extension.py:1.12->1.13 msvccompiler.py:1.49->1.50 mwerkscompiler.py:1.10->1.11 sysconfig.py:1.51->1.52 unixccompiler.py:1.48->1.49 command/build_ext.py:1.87->1.88 command/config.py:1.12->1.13 Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 12:53 Message: Logged In: YES user_id=21627 This patch looks fine, please apply it. If you have spare time, please check out the distutils CVS module, and see whether the tests still pass. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 12:42 Message: Logged In: YES user_id=7887 (I just realized I posted the patch to this bug, and not the one I told. Sorry) Ok.. I'm attaching a new patch including your suggestions. A few comments: - Instead of setting cpp_linker, I'm now using compiler_cxx, as that's what it really is right now, from a Makefile point of view. Other compilers may want to use it in different places. - I'm now checking if compiler_cxx is set before using it. In the worst case, the old behavior will be used, hoping for the best. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 08:12 Message: Logged In: YES user_id=21627 A couple of comments: - distutils should stay compatible with earlier versions of Python, back to 1.5.2. So don't use isinstance(value, list), as list might be a function - cpp_ might be confused as having to do with the preprocessor; I recommend to use cxx_ throughout - You should check whether CXX is set. If it isn't, and you need to compile a C++ file, you should probably raise an exception. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 02:19 Message: Logged In: YES user_id=7887 I'm attaching a proposed solution. Here is how the magic is done: There's a new CCompiler.detect_language() method, which based on the sources extensions and on language_map and language_order class variables (subclasses can overload these), determine what's the "target language" of a set of source files. This target language is passed to every CCompiler method which deals with the linkage step (create_static_lib(), link(), and link_*()). UnixCCompiler uses this information to replace the linking command (if the target language is c++) with cpp_linker[0], which is set on sysconfig.py:customize_compiler(). Other classes, such as msvccompiler.py, could also use the same infrastructure to remove some of the hardcoded extension tests already there. Additionally, an Extension can set the "language" parameter to hardcode a language in setup.py. (PS. this patch also fixes some wrong prototypes of create_static_libs()) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-18 12:55 Message: Logged In: YES user_id=6380 reassigned to amk who should know ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-18 06:47 Message: Logged In: YES user_id=29957 can this be closed as a duplicate of 454030? That one has a real submitter, and some more info... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:51 Message: Logged In: YES user_id=6380 Assigning this to Andrew, who is the current distutils maintainer. ---------------------------------------------------------------------- Comment By: Andrei Tovtchigretchko (andreitd) Date: 2001-04-05 00:23 Message: Logged In: YES user_id=189208 Follow-up: If I link with a static library (-lboost_python is libboost_python.a in bug post example), the problem shows. If I link with shared c++ library (libboost_python.so), everything is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470 From noreply@sourceforge.net Tue Nov 5 17:04:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 09:04:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC Message-ID: Bugs item #454030, was opened at 2001-08-21 23:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: distutils cannot link C++ code with GCC Initial Comment: It is mandatory to link C++ code against -lstdc++ -lm when creating an extension. distutils does not do this in 2.1.1 Here is a setup.py for Python CXX that works around the problem, but it would be better for distutils to understand enough about C++ to do the right thing. THen the code for other compilers could be added. But GCC is important enough to do first. You can get the CXX sources from http://sourceforge.net/projects/cxx/ from distutils.core import setup, Extension if os.name == 'posix': CXX_libraries = ['stdc++','m'] else: CXX_libraries = [] setup(name="pycxx_demo", version="1.0", ext_modules= [Extension( "example", sources = [ "Demo/example.cxx", "Demo/python.cxx", "Demo/range.cxx", "Demo/rangetest.cxx", "Src/cxx_extensions.cxx", "Src/cxxextensions.c", "Src/cxxsupport.cxx", "Src/IndirectPythonInterface.cxx" ], include_dirs = [ ".", "Demo" ], libraries = CXX_libraries ) ] ) ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 17:04 Message: Logged In: YES user_id=7887 Fixed in bug #413582. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:32 Message: Logged In: YES user_id=33168 Barry, is this still a problem w/2.2.2? ---------------------------------------------------------------------- Comment By: Barry Alan Scott (barry-scott) Date: 2002-01-27 11:42 Message: Logged In: YES user_id=28665 Yes using G++ is another way to solve this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 10:08 Message: Logged In: YES user_id=6656 Is this the same problem as [ #413582 ] g++ must be called for c++ extensions ? Not a rhetorical question, I would like to know! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 21:50 Message: Logged In: YES user_id=6380 Nobody at PL understands distutils well enough to do this, so lowering the priority -- there's no way this will hold up the release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 From noreply@sourceforge.net Tue Nov 5 17:39:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 09:39:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-633858 ] trouble printing mimelib.pdf Message-ID: Bugs item #633858, was opened at 2002-11-05 10:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633858&group_id=5470 Category: Documentation >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Grant Griffin (dspguru) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: trouble printing mimelib.pdf Initial Comment: I could not print pages 2, 11, and 24 of the PDF form of "mimelib.pdf", which is the manual for the new email, (BTW, why not rename it to "email.pdf"?) I tried using two different printers from two different manufacturers, and I tried printing from within Internet Explorer as well as from within Acrobat Reader. In each case, I got the message, "The document could not be printed". Other pages printed fine--though printing always stopped at the point of the offending page. (I therefore had print it in segments, less pages 2, 11, and 24.) My guess is that there is something unusual on these pages that is not friendly to printers, oncethe source document gets translated to PDF. (I apologize in advance if this has previously reported and/or is a cockpit error on my part--as my bug reports usually are .) thanks, =g2 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-05 12:39 Message: Logged In: YES user_id=3066 I don't know where mimelib.pdf gets distributed at all; presumably as part of the separate distribution of the email package. (The source in Python's CVS is called mimelib since the name email was already used for the inner portion of the reference manual.) Barry should rename it to something more appropriate for distribution. The printing issue is discussed on the download page for Python's documentation: http://www.python.org/doc/current/download.html Closing this as a third-party bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633858&group_id=5470 From noreply@sourceforge.net Tue Nov 5 17:56:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 09:56:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-633930 ] Nested class __name__ Message-ID: Bugs item #633930, was opened at 2002-11-05 12:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Nested class __name__ Initial Comment: The __name__ attribute of a nested class should be set to 'outer.inner', both for classic and for new-style classes. E.g. >>> class C: ... class C1: pass ... >>> C.C1.__name__ 'C.C1' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 From noreply@sourceforge.net Tue Nov 5 18:02:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 10:02:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-633935 ] test_bz2 fails Message-ID: Bugs item #633935, was opened at 2002-11-05 18:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633935&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 6 Submitted By: Jeremy Hylton (jhylton) Assigned to: Gustavo Niemeyer (niemeyer) Summary: test_bz2 fails Initial Comment: I just did a cvs update and a fresh build of Python dies with a segfault immediately after running test_bz2. build-pydebug> ./python ../Lib/test/regrtest.py test_bz2 test_grammar test_bz2 /usr/home/jeremy/src/python/dist/src/Lib/test/test_bz2.py:30: RuntimeWarning: mktemp is a potential security risk to your program self.filename = tempfile.mktemp("bz2") test_grammar Segmentation fault (core dumped) A partial gdb stack trace shows that it's dying in PyObject_Malloc(). I'm running with a debug build of Python. Not sure what, if anything, it would do with a release build. #0 0x080828b7 in PyObject_Malloc (nbytes=17) at ../Objects/obmalloc.c:581 #1 0x08082f5c in _PyObject_DebugMalloc (nbytes=1) at ../Objects/obmalloc.c:992 #2 0x080553e5 in parsetok (tok=0x81b2fc0, g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:137 #3 0x08055218 in PyParser_ParseStringFlagsFilename ( s=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", filename=0x0, g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:56 #4 0x08055156 in PyParser_ParseStringFlags ( s=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:31 #5 0x080e653f in PyParser_SimpleParseStringFlags ( str=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", start=257, flags=0) at ../Python/pythonrun.c:1193 #6 0x080e6580 in PyParser_SimpleParseString ( str=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", start=257) at ../Python/pythonrun.c:1203 #7 0x080e5fbc in PyRun_String ( str=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", start=257, globals=0x4020c994, locals=0x4020c3f4) at ../Python/pythonrun.c:1025 #8 0x080c431e in exec_statement (f=0x818410c, prog=0x401fcd28, globals=0x4020c994, locals=0x4020c3f4) at ../Python/ceval.c:3786 #9 0x080bca30 in eval_frame (f=0x818410c) at ../Python/ceval.c:1539 #10 0x080c0b69 in PyEval_EvalCodeEx (co=0x40263b28, globals=0x4020c994, locals=0x0, args=0x815907c, argcount=0, kws=0x815907c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2542 #11 0x080c2996 in fast_function (func=0x402222b4, pp_stack=0xbfffe328, n=0, na=0, nk=0) at ../Python/ceval.c:3282 #12 0x080c2818 in call_function (pp_stack=0xbfffe328, oparg=0) at ../Python/ceval.c:3251 #13 0x080beb80 in eval_frame (f=0x8158f24) at ../Python/ceval.c:1997 #14 0x080c0b69 in PyEval_EvalCodeEx (co=0x4021e238, globals=0x4020c994, locals=0x4020c994, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2542 #15 0x080b6abc in PyEval_EvalCode (co=0x4021e238, globals=0x4020c994, locals=0x4020c994) at ../Python/ceval.c:478 #16 0x080dadc3 in PyImport_ExecCodeModuleEx ( name=0xbfffed48 "test.test_grammar", co=0x4021e238, pathname=0xbfffe440 "/usr/home/jeremy/src/python/dist/src/Lib/test/test_grammar.pyc") at ../Python/import.c:530 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633935&group_id=5470 From noreply@sourceforge.net Tue Nov 5 18:15:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 10:15:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 08:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-05 18:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 11:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Tue Nov 5 18:17:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 10:17:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-633935 ] test_bz2 fails Message-ID: Bugs item #633935, was opened at 2002-11-05 13:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633935&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_bz2 fails Initial Comment: I just did a cvs update and a fresh build of Python dies with a segfault immediately after running test_bz2. build-pydebug> ./python ../Lib/test/regrtest.py test_bz2 test_grammar test_bz2 /usr/home/jeremy/src/python/dist/src/Lib/test/test_bz2.py:30: RuntimeWarning: mktemp is a potential security risk to your program self.filename = tempfile.mktemp("bz2") test_grammar Segmentation fault (core dumped) A partial gdb stack trace shows that it's dying in PyObject_Malloc(). I'm running with a debug build of Python. Not sure what, if anything, it would do with a release build. #0 0x080828b7 in PyObject_Malloc (nbytes=17) at ../Objects/obmalloc.c:581 #1 0x08082f5c in _PyObject_DebugMalloc (nbytes=1) at ../Objects/obmalloc.c:992 #2 0x080553e5 in parsetok (tok=0x81b2fc0, g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:137 #3 0x08055218 in PyParser_ParseStringFlagsFilename ( s=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", filename=0x0, g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:56 #4 0x08055156 in PyParser_ParseStringFlags ( s=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", g=0x81466a8, start=257, err_ret=0xbfffdfe0, flags=0) at ../Parser/parsetok.c:31 #5 0x080e653f in PyParser_SimpleParseStringFlags ( str=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", start=257, flags=0) at ../Python/pythonrun.c:1193 #6 0x080e6580 in PyParser_SimpleParseString ( str=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", start=257) at ../Python/pythonrun.c:1203 #7 0x080e5fbc in PyRun_String ( str=0x401fcd44 "if 1:\n exec u'z=1+1\n'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\'\\n'\n del z\n exec u'z=1+1'\n if z != 2: raise TestFailed, 'exec u\'z=1+1\''\n", start=257, globals=0x4020c994, locals=0x4020c3f4) at ../Python/pythonrun.c:1025 #8 0x080c431e in exec_statement (f=0x818410c, prog=0x401fcd28, globals=0x4020c994, locals=0x4020c3f4) at ../Python/ceval.c:3786 #9 0x080bca30 in eval_frame (f=0x818410c) at ../Python/ceval.c:1539 #10 0x080c0b69 in PyEval_EvalCodeEx (co=0x40263b28, globals=0x4020c994, locals=0x0, args=0x815907c, argcount=0, kws=0x815907c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2542 #11 0x080c2996 in fast_function (func=0x402222b4, pp_stack=0xbfffe328, n=0, na=0, nk=0) at ../Python/ceval.c:3282 #12 0x080c2818 in call_function (pp_stack=0xbfffe328, oparg=0) at ../Python/ceval.c:3251 #13 0x080beb80 in eval_frame (f=0x8158f24) at ../Python/ceval.c:1997 #14 0x080c0b69 in PyEval_EvalCodeEx (co=0x4021e238, globals=0x4020c994, locals=0x4020c994, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2542 #15 0x080b6abc in PyEval_EvalCode (co=0x4021e238, globals=0x4020c994, locals=0x4020c994) at ../Python/ceval.c:478 #16 0x080dadc3 in PyImport_ExecCodeModuleEx ( name=0xbfffed48 "test.test_grammar", co=0x4021e238, pathname=0xbfffe440 "/usr/home/jeremy/src/python/dist/src/Lib/test/test_grammar.pyc") at ../Python/import.c:530 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-05 13:17 Message: Logged In: YES user_id=33168 Needed to initialize ret, otherwise, it could Py_XDECREF() uninit memory. Checked in as bz2module.c 1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633935&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:02:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:02:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips Message-ID: Bugs item #410541, was opened at 2001-03-22 16:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: bdist builds bogus .zips Initial Comment: According to Thomas Heller: "... the resulting zip-file from 'bdist --formats=zip' is unusable because it contains filenames relative to the root directory)" Such paths may be OK for Unix (cd / and unzip it, perhaps?), but isn't much good for Windows, where Python might be installed anywhere. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 20:02 Message: Logged In: YES user_id=7887 I don't think we should remove that command. It does no harm being there, and it already allows one to install in any directory. For example, the following command allows one to build a zip file relative to "site-packages/". python setup.py bdist_dumb --format=zip install --install-lib /site-packages OTOH, there are some issues here: - what should be done about script files, which would usually be included in /usr/bin on a unix system? binaries can be moved as well, using the same mechanism explained above, but currently there's no standard place to but them; - a binary distribution could include machine specific binaries; I think the original author had this issues in mind when created the bdist_dumb command, and that's why it even includes the platform name in the generated file. About not being able to use it in different python major versions, that's a binary distrubtion. Other binary distributions, like rpm, behave in the same way. Also, binary compatibility between major versions is not guaranteed, AFAIK. Having in mind these issues, my suggestion is to close that bug and leave the command as is. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 15:29 Message: Logged In: YES user_id=11105 Yes. We would have to remove everything except 'rpm' and 'wininst' from bdist's available formats lists. But it seems the right way to do. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-26 14:52 Message: Logged In: YES user_id=11375 Why not just remove bdist_dumb, then? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 14:07 Message: Logged In: YES user_id=11105 IMO it is impossible to create a dumb binary distribution which can be used to install a package - even on the same platform for different Python versions. So it seems the only possibility is document dumb binary distros as broken. The DISTUTILS TODO list is mainly just a list of thoughts from the previous maintainer, nobody (so far) is caring too much about it currently. Assigning to AMK: Andrew, if you think this is ok, let us close this bug. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-03-06 20:33 Message: Logged In: YES user_id=149084 I'm not sure what is meant by "everyone should install from source or the native binary for his platform." My understanding is that Distutils was created to provide a uniform way to install third party packages. It seems that bdist_dumb has problems building a package distribution which will install properly. What about non-Linux or Windows systems? It rather looks like the code is unfinished.... To quote the TODO (DISTUTILS 1.1 PLANS): "* bdist_dumb should grow a little intelligence: let packager choose whether to make archive relative to prefix or the root (prefix is essential for proper Windows support )" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-05 21:08 Message: Logged In: YES user_id=11105 I expect nobody will install from a zip-file on windows, either. I suggest making bdist_wininst the default bdist format on windows and forget this one: Everyone should (will?) install either from source, or from the native binary distribution for his platform. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 22:54 Message: Logged In: YES user_id=31392 Can you look at this one, Thomas? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-27 22:33 Message: Logged In: YES user_id=149084 gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.) The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do? It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages. Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user. GvR seems to be interested in making the install trees the same on Linux and Windows, that would help. Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist? If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 20:39 Message: Logged In: YES user_id=11375 I expect no one will install from a .zip file on Unix. Options: 1) Make both the .tgz and .zip relative to sys.prefix or something. 2) Make only the .zip relative. 3) Document this as being broken and forget about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:07:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:07:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips Message-ID: Bugs item #410541, was opened at 2001-03-22 17:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: bdist builds bogus .zips Initial Comment: According to Thomas Heller: "... the resulting zip-file from 'bdist --formats=zip' is unusable because it contains filenames relative to the root directory)" Such paths may be OK for Unix (cd / and unzip it, perhaps?), but isn't much good for Windows, where Python might be installed anywhere. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-05 21:07 Message: Logged In: YES user_id=11105 I don't have a strong opinion any longer. Closing the bug with postponed or wont fix is fine with me. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 21:02 Message: Logged In: YES user_id=7887 I don't think we should remove that command. It does no harm being there, and it already allows one to install in any directory. For example, the following command allows one to build a zip file relative to "site-packages/". python setup.py bdist_dumb --format=zip install --install-lib /site-packages OTOH, there are some issues here: - what should be done about script files, which would usually be included in /usr/bin on a unix system? binaries can be moved as well, using the same mechanism explained above, but currently there's no standard place to but them; - a binary distribution could include machine specific binaries; I think the original author had this issues in mind when created the bdist_dumb command, and that's why it even includes the platform name in the generated file. About not being able to use it in different python major versions, that's a binary distrubtion. Other binary distributions, like rpm, behave in the same way. Also, binary compatibility between major versions is not guaranteed, AFAIK. Having in mind these issues, my suggestion is to close that bug and leave the command as is. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 16:29 Message: Logged In: YES user_id=11105 Yes. We would have to remove everything except 'rpm' and 'wininst' from bdist's available formats lists. But it seems the right way to do. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-26 15:52 Message: Logged In: YES user_id=11375 Why not just remove bdist_dumb, then? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 15:07 Message: Logged In: YES user_id=11105 IMO it is impossible to create a dumb binary distribution which can be used to install a package - even on the same platform for different Python versions. So it seems the only possibility is document dumb binary distros as broken. The DISTUTILS TODO list is mainly just a list of thoughts from the previous maintainer, nobody (so far) is caring too much about it currently. Assigning to AMK: Andrew, if you think this is ok, let us close this bug. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-03-06 21:33 Message: Logged In: YES user_id=149084 I'm not sure what is meant by "everyone should install from source or the native binary for his platform." My understanding is that Distutils was created to provide a uniform way to install third party packages. It seems that bdist_dumb has problems building a package distribution which will install properly. What about non-Linux or Windows systems? It rather looks like the code is unfinished.... To quote the TODO (DISTUTILS 1.1 PLANS): "* bdist_dumb should grow a little intelligence: let packager choose whether to make archive relative to prefix or the root (prefix is essential for proper Windows support )" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-05 22:08 Message: Logged In: YES user_id=11105 I expect nobody will install from a zip-file on windows, either. I suggest making bdist_wininst the default bdist format on windows and forget this one: Everyone should (will?) install either from source, or from the native binary distribution for his platform. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 23:54 Message: Logged In: YES user_id=31392 Can you look at this one, Thomas? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-28 00:33 Message: Logged In: YES user_id=149084 gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.) The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do? It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages. Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user. GvR seems to be interested in making the install trees the same on Linux and Windows, that would help. Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist? If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 22:39 Message: Logged In: YES user_id=11375 I expect no one will install from a .zip file on Unix. Options: 1) Make both the .tgz and .zip relative to sys.prefix or something. 2) Make only the .zip relative. 3) Document this as being broken and forget about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:16:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:16:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips Message-ID: Bugs item #410541, was opened at 2001-03-22 11:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: bdist builds bogus .zips Initial Comment: According to Thomas Heller: "... the resulting zip-file from 'bdist --formats=zip' is unusable because it contains filenames relative to the root directory)" Such paths may be OK for Unix (cd / and unzip it, perhaps?), but isn't much good for Windows, where Python might be installed anywhere. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-05 15:16 Message: Logged In: YES user_id=11375 I still lean toward removing it. What platforms are there where one would install by just unzipping a file? Linux? No, everyone uses RPM or DEB. (Maybe Slackware...) FreeBSD? No, there's the ports system. Windows and Mac? No, people want installers. Should we take this discussion to distutils-sig or python-dev, perhaps? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 15:07 Message: Logged In: YES user_id=11105 I don't have a strong opinion any longer. Closing the bug with postponed or wont fix is fine with me. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 15:02 Message: Logged In: YES user_id=7887 I don't think we should remove that command. It does no harm being there, and it already allows one to install in any directory. For example, the following command allows one to build a zip file relative to "site-packages/". python setup.py bdist_dumb --format=zip install --install-lib /site-packages OTOH, there are some issues here: - what should be done about script files, which would usually be included in /usr/bin on a unix system? binaries can be moved as well, using the same mechanism explained above, but currently there's no standard place to but them; - a binary distribution could include machine specific binaries; I think the original author had this issues in mind when created the bdist_dumb command, and that's why it even includes the platform name in the generated file. About not being able to use it in different python major versions, that's a binary distrubtion. Other binary distributions, like rpm, behave in the same way. Also, binary compatibility between major versions is not guaranteed, AFAIK. Having in mind these issues, my suggestion is to close that bug and leave the command as is. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 10:29 Message: Logged In: YES user_id=11105 Yes. We would have to remove everything except 'rpm' and 'wininst' from bdist's available formats lists. But it seems the right way to do. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-26 09:52 Message: Logged In: YES user_id=11375 Why not just remove bdist_dumb, then? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 09:07 Message: Logged In: YES user_id=11105 IMO it is impossible to create a dumb binary distribution which can be used to install a package - even on the same platform for different Python versions. So it seems the only possibility is document dumb binary distros as broken. The DISTUTILS TODO list is mainly just a list of thoughts from the previous maintainer, nobody (so far) is caring too much about it currently. Assigning to AMK: Andrew, if you think this is ok, let us close this bug. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-03-06 15:33 Message: Logged In: YES user_id=149084 I'm not sure what is meant by "everyone should install from source or the native binary for his platform." My understanding is that Distutils was created to provide a uniform way to install third party packages. It seems that bdist_dumb has problems building a package distribution which will install properly. What about non-Linux or Windows systems? It rather looks like the code is unfinished.... To quote the TODO (DISTUTILS 1.1 PLANS): "* bdist_dumb should grow a little intelligence: let packager choose whether to make archive relative to prefix or the root (prefix is essential for proper Windows support )" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-05 16:08 Message: Logged In: YES user_id=11105 I expect nobody will install from a zip-file on windows, either. I suggest making bdist_wininst the default bdist format on windows and forget this one: Everyone should (will?) install either from source, or from the native binary distribution for his platform. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 17:54 Message: Logged In: YES user_id=31392 Can you look at this one, Thomas? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-27 18:33 Message: Logged In: YES user_id=149084 gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.) The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do? It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages. Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user. GvR seems to be interested in making the install trees the same on Linux and Windows, that would help. Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist? If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 16:39 Message: Logged In: YES user_id=11375 I expect no one will install from a .zip file on Unix. Options: 1) Make both the .tgz and .zip relative to sys.prefix or something. 2) Make only the .zip relative. 3) Document this as being broken and forget about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:21:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:21:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips Message-ID: Bugs item #410541, was opened at 2001-03-22 16:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: bdist builds bogus .zips Initial Comment: According to Thomas Heller: "... the resulting zip-file from 'bdist --formats=zip' is unusable because it contains filenames relative to the root directory)" Such paths may be OK for Unix (cd / and unzip it, perhaps?), but isn't much good for Windows, where Python might be installed anywhere. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 20:21 Message: Logged In: YES user_id=7887 Can you please do so? Doing so will allow us to close the issue, taking some action, or just forgetting it. Thank you! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-05 20:16 Message: Logged In: YES user_id=11375 I still lean toward removing it. What platforms are there where one would install by just unzipping a file? Linux? No, everyone uses RPM or DEB. (Maybe Slackware...) FreeBSD? No, there's the ports system. Windows and Mac? No, people want installers. Should we take this discussion to distutils-sig or python-dev, perhaps? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 20:07 Message: Logged In: YES user_id=11105 I don't have a strong opinion any longer. Closing the bug with postponed or wont fix is fine with me. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-05 20:02 Message: Logged In: YES user_id=7887 I don't think we should remove that command. It does no harm being there, and it already allows one to install in any directory. For example, the following command allows one to build a zip file relative to "site-packages/". python setup.py bdist_dumb --format=zip install --install-lib /site-packages OTOH, there are some issues here: - what should be done about script files, which would usually be included in /usr/bin on a unix system? binaries can be moved as well, using the same mechanism explained above, but currently there's no standard place to but them; - a binary distribution could include machine specific binaries; I think the original author had this issues in mind when created the bdist_dumb command, and that's why it even includes the platform name in the generated file. About not being able to use it in different python major versions, that's a binary distrubtion. Other binary distributions, like rpm, behave in the same way. Also, binary compatibility between major versions is not guaranteed, AFAIK. Having in mind these issues, my suggestion is to close that bug and leave the command as is. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 15:29 Message: Logged In: YES user_id=11105 Yes. We would have to remove everything except 'rpm' and 'wininst' from bdist's available formats lists. But it seems the right way to do. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-26 14:52 Message: Logged In: YES user_id=11375 Why not just remove bdist_dumb, then? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-26 14:07 Message: Logged In: YES user_id=11105 IMO it is impossible to create a dumb binary distribution which can be used to install a package - even on the same platform for different Python versions. So it seems the only possibility is document dumb binary distros as broken. The DISTUTILS TODO list is mainly just a list of thoughts from the previous maintainer, nobody (so far) is caring too much about it currently. Assigning to AMK: Andrew, if you think this is ok, let us close this bug. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-03-06 20:33 Message: Logged In: YES user_id=149084 I'm not sure what is meant by "everyone should install from source or the native binary for his platform." My understanding is that Distutils was created to provide a uniform way to install third party packages. It seems that bdist_dumb has problems building a package distribution which will install properly. What about non-Linux or Windows systems? It rather looks like the code is unfinished.... To quote the TODO (DISTUTILS 1.1 PLANS): "* bdist_dumb should grow a little intelligence: let packager choose whether to make archive relative to prefix or the root (prefix is essential for proper Windows support )" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-05 21:08 Message: Logged In: YES user_id=11105 I expect nobody will install from a zip-file on windows, either. I suggest making bdist_wininst the default bdist format on windows and forget this one: Everyone should (will?) install either from source, or from the native binary distribution for his platform. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 22:54 Message: Logged In: YES user_id=31392 Can you look at this one, Thomas? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-27 22:33 Message: Logged In: YES user_id=149084 gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.) The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do? It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages. Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user. GvR seems to be interested in making the install trees the same on Linux and Windows, that would help. Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist? If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 20:39 Message: Logged In: YES user_id=11375 I expect no one will install from a .zip file on Unix. Options: 1) Make both the .tgz and .zip relative to sys.prefix or something. 2) Make only the .zip relative. 3) Document this as being broken and forget about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:40:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:40:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-05 21:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 23:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 21:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 21:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 10:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 23:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:53:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:53:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-631350 ] string payload expected: Message-ID: Bugs item #631350, was opened at 2002-10-30 20:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631350&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: string payload expected: Initial Comment: This appears to be a bug in email 2.4.3. A TMDA user reported this problem today. With this particular message (an ezmlm multipart/digest), email 2.4.3 throws a TypeError when calling as_string(). Other messages are unproblematic. The traceback and copy of the problematic message are attached. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-05 15:53 Message: Logged In: YES user_id=12800 Yep, this is a real bug. RFC 2046, $5.1.5 recommends against using a content type other than message/rfc822 as a subpart of a multipart/digest, but doesn't make it illegal. I believe I have a patch for this (checking it into Py2.3 cvs) that doesn't cause any other tests to fail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631350&group_id=5470 From noreply@sourceforge.net Tue Nov 5 20:54:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 12:54:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-570655 ] bdist_rpm and the changelog option Message-ID: Bugs item #570655, was opened at 2002-06-18 12:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 Category: Distutils Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: A.M. Kuchling (akuchling) Summary: bdist_rpm and the changelog option Initial Comment: I think the changelog option for bdist_rpm is not correctly handled. The documentation says it should expect a path to a file containing the changelog entries, but in bdist_rpm.py, line 200, it tries to read it as a string (ensure_string etc). The changelogs are multiple lines, and I was unable to add multi-lined entries in setup.cfg. Even so, the documentation is still misleading. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2002-11-05 15:54 Message: Logged In: YES user_id=205865 akuchling: how can you set changelog then? Changelog entries are multi-lined, I did not find a way to set it in setup.cfg. Do I miss something? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:36 Message: Logged In: YES user_id=11375 Option hint fixed in revision 1.33 of bdist_rpm.py; fix also backported to 2.2 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:28 Message: Logged In: YES user_id=11375 Hmm... looking at old versions of bdist_rpm, changelog has always been a string. We can't change it to a path now because that might break existing setup.py file; instead, the documentation should be fixed. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-28 15:57 Message: Logged In: YES user_id=205865 Uploaded a patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:06:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:06:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 15:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 17:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 15:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 15:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:12:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:12:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-05 22:12 Message: Logged In: YES user_id=11105 Great, will do this tomorrow. What about socketmodule.c, which Neal mentioned? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 22:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 21:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 23:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 21:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 21:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 10:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 23:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:14:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:14:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:14 Message: Logged In: YES user_id=31435 If socketmodule isn't crashing, I'd leave it alone. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 16:12 Message: Logged In: YES user_id=11105 Great, will do this tomorrow. What about socketmodule.c, which Neal mentioned? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 15:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 17:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 15:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 15:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:23:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:23:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 16:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 02:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 14:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 00:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 23:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:32:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:32:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-634069 ] Errors in ** docs Message-ID: Bugs item #634069, was opened at 2002-11-05 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Errors in ** docs Initial Comment: Section 5.4 "The power operator" is out of date: 1. Raising a postive int to a negative int power no longer raises TypeError (it returns a float). 2. It's unclear what "a broken power" means. Raising a negative float to a non-integer power raises ValueError (not TypeError), if that's what it means. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:43:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:43:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Tue Nov 5 21:44:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 13:44:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-633527 ] HeaderParseError: no newline Message-ID: Bugs item #633527, was opened at 2002-11-04 18:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: HeaderParseError: no newline Initial Comment: This is for email 2.4.3. When trying to parse a message which lacks a newline separating the header and body, email throws a HeaderParseError: email.Errors.HeaderParseError: Not a header, not a continuation: ``foobar.'' However, the rfc822 package is able to correctly parse such a message into separate header and body portions. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-05 16:44 Message: Logged In: YES user_id=12800 Ok, under lax parsing, I think it's fine for the first non-header line to be interpreted as a body line. I seem to remember problems with rfc822 in this regard, so it makes me a little nervous, but I can't remember the details. I guess we'll find out! ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-04 18:10 Message: Logged In: YES user_id=85984 Also see the following more on this problem: http://article.gmane.org/gmane.mail.spam.tmda.user/7007 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633527&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:11:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:11:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-631247 ] Mac OS 10 configure problem Message-ID: Bugs item #631247, was opened at 2002-10-30 22:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631247&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Jack Jansen (jackjansen) Summary: Mac OS 10 configure problem Initial Comment: Using the Python CVS head from about two days ago: Under Mac OS 10 configure --enable-framework; make fails if the source directory is on a NFS mounted disk, but the build directory in a case insensitive Mac volume. According to Jack Jansen this is because configure checks if the source directory is on a file system that is case insensitive, when it should be checking the file system with the build directory: if test -d "${srcdir}/python" then echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 BUILDEXEEXT=.exe else echo "$as_me:$LINENO: result: no" >&5 echo "${ECHO_T}no" >&6 BUILDEXEEXT=$EXEEXT fi ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-11-05 23:11 Message: Logged In: YES user_id=45365 Attaching a patch that I still need to review on a case sensitive system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631247&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:13:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:13:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:14:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:14:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:16:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:16:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 17:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 17:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:24:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:24:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:24 Message: Logged In: YES user_id=21627 Maybe. This would be a deviation from the past, so I'm sure users will be surprised if 'make install' does that. For people building binary distributions, there probably needs to be a target that does the traditional install only, or they need to invoke altinstall bininstall maninstall but not idleinstall. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:26:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:26:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-634116 ] pdb quit breakage Message-ID: Bugs item #634116, was opened at 2002-11-05 17:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634116&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: pdb quit breakage Initial Comment: Behold: >>> import pdb >>> pdb.run("pass") > (1)?() (Pdb) q >>> pdb.run("pass") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/usr/local/lib/python2.3/bdb.py", line 61, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit >>> pdb.run("pass") > (1)?() (Pdb) q >>> IOW, quitting out of pdb causes some sticky state to remain behind which sabotages the next call to pdb.run(). This bug is new in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634116&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:31:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:31:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 17:31 Message: Logged In: YES user_id=6380 Actually, I believe I've seen a Linux distro that had idle installed. And what's wrong with installing idle? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 17:24 Message: Logged In: YES user_id=21627 Maybe. This would be a deviation from the past, so I'm sure users will be surprised if 'make install' does that. For people building binary distributions, there probably needs to be a target that does the traditional install only, or they need to invoke altinstall bininstall maninstall but not idleinstall. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 17:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 17:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:33:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:33:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-05 17:33 Message: Logged In: YES user_id=33168 Thomas, I belivee the code below will check if the other cases crash. # test posixmodule.popen(), # would need check around line 2835 # as first code in popen() import posix # you may need a command that works, # I'm guessing cmd.exe is ok posix.popen('cmd.exe', '.zip') # test socketmodule.sock_makefile(), # would need check around line 1572 # after PyArg_ParseTuple from socket import * s = socket(AF_INET, SOCK_STREAM) s.makefile('.zip') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:14 Message: Logged In: YES user_id=31435 If socketmodule isn't crashing, I'd leave it alone. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 16:12 Message: Logged In: YES user_id=11105 Great, will do this tomorrow. What about socketmodule.c, which Neal mentioned? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 15:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 17:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 15:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 15:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:49:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:49:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-629097 ] Race condition in asyncore poll Message-ID: Bugs item #629097, was opened at 2002-10-26 10:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629097&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steve Alexander (stevea_zope) Assigned to: Nobody/Anonymous (nobody) Summary: Race condition in asyncore poll Initial Comment: In the following post to the Zope 3 developers' list, I describe a race condition in the poll method of asyncore. http://lists.zope.org/pipermail/zope3-dev/2002-October/003091.html The problem is this: There is a global dict socket_map. In the poll method, socket_map is processed into appropriate arguments for a select.select call. However, if a socket that is represented socket_map is closed during the time between the processing of socket_map and the select.select call, that call will fail with a Bad File Descriptor (EBADF) error. One solution is to patch asyncore to catch EBADF errors raised by select.select, and at that point see if the file descriptors in the current version of socket_map are the same as in the processed data used for the select.select call. If they are the same, re-raise the error, otherwise, ignore the error. In another email to the Zope 3 developers' list, Jeremy Hylton queries whether there are any other similar problems in asyncore. http://lists.zope.org/pipermail/zope3-dev/2002-October/003093.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 17:49 Message: Logged In: YES user_id=6380 According to Jeremy, this is more a matter of "don't do that". The right solution is to make sure that sockets are only closed by the main thread (the thread running asyncore.loop()). I wonder if we should just close this bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629097&group_id=5470 From noreply@sourceforge.net Tue Nov 5 23:05:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 15:05:49 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-633543 ] Korean support, unknown charsets Message-ID: Feature Requests item #633543, was opened at 2002-11-04 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Korean support, unknown charsets Initial Comment: The following patch needs to be integrated into the email package: http://article.gmane.org/gmane.comp.python.mime.devel/250 Most of it was delayed due to the impending Python 2.2.2 release, but the patch is important, and I don't want to see the work lost. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-05 16:05 Message: Logged In: YES user_id=85984 See http://article.gmane.org/gmane.comp.python.mime.devel/319 for the Charset.py portion of the patch against current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 From noreply@sourceforge.net Tue Nov 5 22:57:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 14:57:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:57 Message: Logged In: YES user_id=21627 Nothing is wrong with installing IDLE. On the particular distro, IDLE may have come from a separate RPM, though: IDLE depends on Tkinter, which depends on Tcl/Tk, which depends on X11. So installing IDLE has more prerequisites than installing Python itself. That's why distros like to split Tkinter, and subsequently IDLE, into a separate package, so you can install Python without installing X11. All I'm asking is that install-idle is a separate sub-target, so that you *can* install Python without installing IDLE. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:31 Message: Logged In: YES user_id=6380 Actually, I believe I've seen a Linux distro that had idle installed. And what's wrong with installing idle? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:24 Message: Logged In: YES user_id=21627 Maybe. This would be a deviation from the past, so I'm sure users will be surprised if 'make install' does that. For people building binary distributions, there probably needs to be a target that does the traditional install only, or they need to invoke altinstall bininstall maninstall but not idleinstall. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Wed Nov 6 04:14:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 20:14:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-634246 ] for line in file iterator ignores codecs Message-ID: Bugs item #634246, was opened at 2002-11-06 04:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Aumann (gaumann) Assigned to: M.-A. Lemburg (lemburg) Summary: for line in file iterator ignores codecs Initial Comment: If you use the old file reading idiom with a codec the lines are converted to unicode but if you use the new iterators idiom then they retain the original encoding and are returned in non unicode strings. Using the new "for line in file:" idiom should give the same result as the old, "while 1: ...." I came across this when using the pythonzh Chinese codecs but the below code uses the cp1252 encoding to illustrate the problem because everyone should have those codecs. The symptoms are the same with both codecs. I am using python 2.2.2 on win2k. The following code illustrates the problem: ------------------------------------------------------------------------ """Check readline iterator using a codec.""" import codecs fname = 'tmp.txt' f = file(fname, 'w') for i in range(0x82, 0x8c): f.write( '%x, %s\n' % (i, chr(i))) f.close() def test_iter(): print '\ntesting codec iterator.' f = codecs.open(fname, 'r', 'cp1252') for line in f: l = line.rstrip() print repr(l) print repr(l.decode('cp1252')) f.close() def test_readline(): print '\ntesting codec readline.' f = codecs.open(fname, 'r', 'cp1252') while 1: line = f.readline() if not line: break l = line.rstrip() print repr(l) try: print repr(l.decode('cp1252')) except AttributeError, msg: print 'AttributeError', msg f.close() test_iter() test_readline() ------------------------------------------------------------------------ This code gives the following output: ------------------------------------------------------------------------ testing codec iterator. '82, \x82' u'82, \u201a' '83, \x83' u'83, \u0192' '84, \x84' u'84, \u201e' '85, \x85' u'85, \u2026' '86, \x86' u'86, \u2020' '87, \x87' u'87, \u2021' '88, \x88' u'88, \u02c6' '89, \x89' u'89, \u2030' '8a, \x8a' u'8a, \u0160' '8b, \x8b' u'8b, \u2039' testing codec readline. u'82, \u201a' AttributeError 'unicode' object has no attribute 'decode' u'83, \u0192' AttributeError 'unicode' object has no attribute 'decode' u'84, \u201e' AttributeError 'unicode' object has no attribute 'decode' u'85, \u2026' AttributeError 'unicode' object has no attribute 'decode' u'86, \u2020' AttributeError 'unicode' object has no attribute 'decode' u'87, \u2021' AttributeError 'unicode' object has no attribute 'decode' u'88, \u02c6' AttributeError 'unicode' object has no attribute 'decode' u'89, \u2030' AttributeError 'unicode' object has no attribute 'decode' u'8a, \u0160' AttributeError 'unicode' object has no attribute 'decode' u'8b, \u2039' AttributeError 'unicode' object has no attribute 'decode' ------------------------------------------------------------------------ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 From noreply@sourceforge.net Wed Nov 6 04:55:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Nov 2002 20:55:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-633480 ] IOError w/ large string to CMD shell Message-ID: Bugs item #633480, was opened at 2002-11-04 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 Category: Windows >Group: 3rd Party Status: Open Resolution: None Priority: 4 Submitted By: Michael McCandless (mikemccand) >Assigned to: Tim Peters (tim_one) Summary: IOError w/ large string to CMD shell Initial Comment: If I try to run this program with "python2.2.1 -u": # 61409 works!! print ' ' * 61410 (which tries to print a string of 61,410 space characters), I get this Traceback on Windows 2000 SP2: Traceback (most recent call last): File "write.py", line 4, in ? print ' ' * 61410 IOError: [Errno 12] Not enough space Without "-u", this runs fine, and if I change "print" to "import sys; sys.stdout.write" instead, it still fails. I think this is happening in Objects/fileobject.c -- the calls to fwrite apparently don't write all bytes in win32 when the number of bytes is large -- seems like it may be necessary to parcel the data up into smaller pieces or something? NOTE: it's possible that the exact length of the string that fails may be larger on other OS's... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-05 23:55 Message: Logged In: YES user_id=31435 The thing is, if you want to do this, you're going to *have* to worm around it. I've got no magic to offer -- it's a vanilla C library call, and there's no sign that Python has anything to do with the failure. Try doing a staight fwrite() to stdout, unbuffered, in C, and I expect you'll see the same thing (or if not, then *maybe* Python had something to do with it). If it does fail in straight C, then filing a bug report with Microsoft is appropriate. Or you could upgrade to Win98 . Assigning to me and marking 3rdParty; I expect to close it as WontFix unless evidence appears that not a Windows bug. BTW, you may have better luck installing the Python Win32 extensions and using the Win32 file API directly. Sometimes that works better than MS's std-C I/O implementation. ---------------------------------------------------------------------- Comment By: Michael McCandless (mikemccand) Date: 2002-11-05 08:29 Message: Logged In: YES user_id=323786 Thanks for looking into this Tim... True, we can workaround it -- either don't run UNBUFFERED, or break up the strings before printing (override sys.stdout w/ our own file object that tries to break things up before printing), or don't run under "CMD" or other platform-specific shells that have this issue. But it's rather unexpected and to a "Python newbie" would be "surprising"; though I suppose most would not run with "- u". Also, from the IOError that's raised I don't know how many bytes were actually successfully written (apparently 0 in this case). NOTE: I'm able to reproduce on Windows XP Professional (no SP), running "cmd.exe", Python 2.2.2. I've also tried changing the "screen buffer" sizes on the CMD and it does not seem to change things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 16:34 Message: Logged In: YES user_id=31435 Couldn't reproduce under Win98SE and 2.2.2 even boosting the size to a million. It *may* have to do with console-size settings under cmd.exe. Reduced the priority. "So don't do that" comes to mind . Seriously, if the platform C fwrite chokes, it's not Python's job to fix it -- it's Microsoft's. The interpreter isn't dying here, it's raising a well-behaved exception, just passing on the error the platform fwrite() raised. To me it's the same as the system malloc complaining that you don't have enough memory to satisfy a request: you've exceeded a platform limitation. If this is important to you, you can presumably fix it yourself by chunking up your writes in a loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 From noreply@sourceforge.net Wed Nov 6 08:45:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 00:45:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 09:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 09:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 19:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 12:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Wed Nov 6 11:21:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 03:21:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 08:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-06 11:21 Message: Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 08:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 18:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 11:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Wed Nov 6 11:47:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 03:47:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-633480 ] IOError w/ large string to CMD shell Message-ID: Bugs item #633480, was opened at 2002-11-04 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 Category: Windows Group: 3rd Party Status: Open Resolution: None Priority: 4 Submitted By: Michael McCandless (mikemccand) Assigned to: Tim Peters (tim_one) Summary: IOError w/ large string to CMD shell Initial Comment: If I try to run this program with "python2.2.1 -u": # 61409 works!! print ' ' * 61410 (which tries to print a string of 61,410 space characters), I get this Traceback on Windows 2000 SP2: Traceback (most recent call last): File "write.py", line 4, in ? print ' ' * 61410 IOError: [Errno 12] Not enough space Without "-u", this runs fine, and if I change "print" to "import sys; sys.stdout.write" instead, it still fails. I think this is happening in Objects/fileobject.c -- the calls to fwrite apparently don't write all bytes in win32 when the number of bytes is large -- seems like it may be necessary to parcel the data up into smaller pieces or something? NOTE: it's possible that the exact length of the string that fails may be larger on other OS's... ---------------------------------------------------------------------- >Comment By: Michael McCandless (mikemccand) Date: 2002-11-06 06:47 Message: Logged In: YES user_id=323786 Tim, Okay -- that sounds like the right approach here -- thanks again. Don't think I'll be upgrading to Win98 too soon :) And I don't have high hopes on getting a fix out of MSFT :) Mike ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 23:55 Message: Logged In: YES user_id=31435 The thing is, if you want to do this, you're going to *have* to worm around it. I've got no magic to offer -- it's a vanilla C library call, and there's no sign that Python has anything to do with the failure. Try doing a staight fwrite() to stdout, unbuffered, in C, and I expect you'll see the same thing (or if not, then *maybe* Python had something to do with it). If it does fail in straight C, then filing a bug report with Microsoft is appropriate. Or you could upgrade to Win98 . Assigning to me and marking 3rdParty; I expect to close it as WontFix unless evidence appears that not a Windows bug. BTW, you may have better luck installing the Python Win32 extensions and using the Win32 file API directly. Sometimes that works better than MS's std-C I/O implementation. ---------------------------------------------------------------------- Comment By: Michael McCandless (mikemccand) Date: 2002-11-05 08:29 Message: Logged In: YES user_id=323786 Thanks for looking into this Tim... True, we can workaround it -- either don't run UNBUFFERED, or break up the strings before printing (override sys.stdout w/ our own file object that tries to break things up before printing), or don't run under "CMD" or other platform-specific shells that have this issue. But it's rather unexpected and to a "Python newbie" would be "surprising"; though I suppose most would not run with "- u". Also, from the IOError that's raised I don't know how many bytes were actually successfully written (apparently 0 in this case). NOTE: I'm able to reproduce on Windows XP Professional (no SP), running "cmd.exe", Python 2.2.2. I've also tried changing the "screen buffer" sizes on the CMD and it does not seem to change things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 16:34 Message: Logged In: YES user_id=31435 Couldn't reproduce under Win98SE and 2.2.2 even boosting the size to a million. It *may* have to do with console-size settings under cmd.exe. Reduced the priority. "So don't do that" comes to mind . Seriously, if the platform C fwrite chokes, it's not Python's job to fix it -- it's Microsoft's. The interpreter isn't dying here, it's raising a well-behaved exception, just passing on the error the platform fwrite() raised. To me it's the same as the system malloc complaining that you don't have enough memory to satisfy a request: you've exceeded a platform limitation. If this is important to you, you can presumably fix it yourself by chunking up your writes in a loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 From noreply@sourceforge.net Wed Nov 6 13:14:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 05:14:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-634412 ] RFC 2112 in email package Message-ID: Bugs item #634412, was opened at 2002-11-06 08:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634412&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: RFC 2112 in email package Initial Comment: Figure out if and how to support multipart/related as specified in RFC 2112, in the email package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634412&group_id=5470 From noreply@sourceforge.net Wed Nov 6 13:22:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 05:22:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-11-06 14:22 Message: Logged In: YES user_id=45365 Alternatively, only install Idle if Tkinter works. This is what Mac/OSX/Makefile does for both Idle and IDE: they're only installed if the prerequisite modules work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:57 Message: Logged In: YES user_id=21627 Nothing is wrong with installing IDLE. On the particular distro, IDLE may have come from a separate RPM, though: IDLE depends on Tkinter, which depends on Tcl/Tk, which depends on X11. So installing IDLE has more prerequisites than installing Python itself. That's why distros like to split Tkinter, and subsequently IDLE, into a separate package, so you can install Python without installing X11. All I'm asking is that install-idle is a separate sub-target, so that you *can* install Python without installing IDLE. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:31 Message: Logged In: YES user_id=6380 Actually, I believe I've seen a Linux distro that had idle installed. And what's wrong with installing idle? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:24 Message: Logged In: YES user_id=21627 Maybe. This would be a deviation from the past, so I'm sure users will be surprised if 'make install' does that. For people building binary distributions, there probably needs to be a target that does the traditional install only, or they need to invoke altinstall bininstall maninstall but not idleinstall. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Wed Nov 6 13:35:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 05:35:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-634422 ] global name 'name' is not defined Message-ID: Bugs item #634422, was opened at 2002-11-06 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634422&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Martin v. Löwis (loewis) Assigned to: Jeremy Hylton (jhylton) Summary: global name 'name' is not defined Initial Comment: It appears rev. 1.36 introduced a new error, I get File "/usr/local/lib/python2.3/urllib2.py", line 324, in open '_open', req) File "/usr/local/lib/python2.3/urllib2.py", line 303, in _call_chain result = func(*args) File "/usr/local/lib/python2.3/urllib2.py", line 793, in http_open return self.do_open(httplib.HTTP, req) File "/usr/local/lib/python2.3/urllib2.py", line 774, in do_open if name not in req.headers: NameError: global name 'name' is not defined ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634422&group_id=5470 From noreply@sourceforge.net Wed Nov 6 14:17:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 06:17:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Wed Nov 6 14:20:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 06:20:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Wed Nov 6 14:27:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 06:27:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 15:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Wed Nov 6 14:28:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 06:28:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-470582 ] sre bug with nested groups Message-ID: Bugs item #470582, was opened at 2001-10-12 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=470582&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Fredrik Lundh (effbot) Summary: sre bug with nested groups Initial Comment: sre incorrectly assigns non-matched inner groups. See m.group(2) in the example below. This bug seems to be present in all sre versions (tested with python 1.6.x, 2.0.x, 2.1.x and 2.2a4). Markus P.S. this seems not related to SF bug #468169 Script started on Tue Oct 9 05:09:28 2001 mfx@laetitia:~/tmp > cat sre_bug.py import sys, pre, sre def time2ms(re, time): m = re.search(r"^((\d)\:)?(\d\d)\.(\d\d\d)$", time) print re.__name__ if hasattr(re, "__version__"): print re.__version__ print m.groups() print sys.version time2ms(pre, "34.123") time2ms(sre, "34.123") mfx@laetitia:~/tmp > pyhon2.2a4 sre_bug.py 2.2a4 (#1, Sep 29 2001, 23:40:47) [GCC 2.95.4 20010902 (Debian prerelease)] pre (None, None, '34', '123') sre 2.1.1 (None, '3', '34', '123') Script done on Tue Oct 9 05:09:45 2001 ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-06 14:28 Message: Logged In: YES user_id=7887 Fixed in CVS in the following revisions: Lib/test/re_tests.py:1.30->1.31 Lib/test/test_sre.py:1.37->1.38 Misc/NEWS:1.511->1.512 Modules/_sre.c:2.83->2.84 Thank you very much! ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-03-11 13:51 Message: Logged In: YES user_id=86307 I posted a patch (527371) for this here: http://sourceforge.net/tracker/? func=detail&aid=527371&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=470582&group_id=5470 From noreply@sourceforge.net Wed Nov 6 14:28:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 06:28:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-548109 ] Build fails in _curses module Message-ID: Bugs item #548109, was opened at 2002-04-24 10:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548109&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Ralf Hildebrandt (hildeb) Assigned to: Nobody/Anonymous (nobody) Summary: Build fails in _curses module Initial Comment: WHile building Python-2.2.1 on HP-UX 10.20 I get: ... building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/mnt/disk4/gnu/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c -o build/temp.hp-ux-B.10.20-9000/715-2.2/_cursesmodule.o -DNDEBUG -g -O3 -Wall -Wstrict-prototypes /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_EchoChar': /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: structure has no member named _flags' /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: _ISPAD' undeclared (first use in this function) /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: (Each undeclared identifier is reported only once /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: for each function it appears in.) /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_NoOutRefresh': /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1118: structure has no member named _flags' /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1118: _ISPAD' undeclared (first use in this function) /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_Refresh': /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1260: structure has no member named _flags' /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1260: _ISPAD' undeclared (first use in this function) /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_SubWin': /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1326: structure has no member named _flags' /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1326: _ISPAD' undeclared (first use in this function) /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCurses_tigetflag': /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:2264: warning: implicit declaration of function tigetflag' /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCurses_tigetnum': /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:2277: warning: implicit declaration of function tigetnum' ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 09:28 Message: Logged In: YES user_id=11375 I agree with Michael. The _ISPAD code is inside #ifdef WINDOW_HAS_FLAGS, which is detected by the configure script. It must be getting set to 1, but the compilation is picking up some different header files, or the same headers with different options. The 'implicit declaration of tigetflag' presumably means either your platform doesn't support tigetflag(), in which case the curses module will need more changes to support its absence, or the prototype is in some header file that isn't being included. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-24 10:18 Message: Logged In: YES user_id=6656 Do you have ncurses installed? It looks somewhat like configure is detecting ncurses but the module is being compiled against some lesser curses. Not sure, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548109&group_id=5470 From noreply@sourceforge.net Wed Nov 6 14:54:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 06:54:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-570655 ] bdist_rpm and the changelog option Message-ID: Bugs item #570655, was opened at 2002-06-18 12:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 Category: Distutils Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: A.M. Kuchling (akuchling) Summary: bdist_rpm and the changelog option Initial Comment: I think the changelog option for bdist_rpm is not correctly handled. The documentation says it should expect a path to a file containing the changelog entries, but in bdist_rpm.py, line 200, it tries to read it as a string (ensure_string etc). The changelogs are multiple lines, and I was unable to add multi-lined entries in setup.cfg. Even so, the documentation is still misleading. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 09:54 Message: Logged In: YES user_id=11375 setup.cfg is parsed using ConfigParser.py, which supports multiple-line entries by embedding a newline followed by whitespace. If that doesn't work for some reason, that's another bug; let me know and I'll look into it. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-11-05 15:54 Message: Logged In: YES user_id=205865 akuchling: how can you set changelog then? Changelog entries are multi-lined, I did not find a way to set it in setup.cfg. Do I miss something? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:36 Message: Logged In: YES user_id=11375 Option hint fixed in revision 1.33 of bdist_rpm.py; fix also backported to 2.2 branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:28 Message: Logged In: YES user_id=11375 Hmm... looking at old versions of bdist_rpm, changelog has always been a string. We can't change it to a path now because that might break existing setup.py file; instead, the documentation should be fixed. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-28 15:57 Message: Logged In: YES user_id=205865 Uploaded a patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470 From noreply@sourceforge.net Wed Nov 6 15:01:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 07:01:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-608033 ] Implied __init__.py not copied Message-ID: Bugs item #608033, was opened at 2002-09-11 16:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470 Category: Distutils Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) >Assigned to: A.M. Kuchling (akuchling) Summary: Implied __init__.py not copied Initial Comment: The setup method in distutils won't allow me to specify packages and py_modules, and it doesn't correctly deduce all of the directories that need __init__.py files copied. See the attached setup.py for an example. This setup.py is automatically generated from a cca.sidl file containing an interface description. In my example, the directory structure is as follows: gov/ gov/cca/ gov/cca/ports/ decaf/ decaf/ports The problem is that gov/ only contains __init__.py. If I specific packages and py_modules in my setup call, I see the following: [epperly@tux06 runPython]$ python2.2 setup.py --include-dirs=`cd ../../../runtime/python && pwd` --include-dirs=`cd ../../../runtime/sidl && pwd` --include-dirs=`cd . && pwd` --library-dirs=`cd ../../../runtime/sidl/.libs && pwd` install --prefix=/tmp/pytest running install running build running build_py error: build_py: supplying both 'packages' and 'py_modules' options is not allowed [epperly@tux06 runPython]$ If I comment out the "packages = []" part and do a "python setup.py install", it doesn't copy gov/__init__.py, decaf/__init__.py and decaf/ports/__init__.py to the installation directory. >From this data, it appears that distutils isn't deducing the package list correctly from py_modules and ext_modules. For each element of py_modules, it should add all the parent modules. For an py_modules entry, a.b.c.d.e.f, distutils should add a, a.b, a.b.c, a.b.c.d, and a.b.c.d.e to the package list. distutils should also glean package names from the ext_modules list. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:01 Message: Logged In: YES user_id=11375 Actually, it looks like there's code in build_py.py that does add the __init__.py file; see the find_modules() method. It must be broken in some way. I'll look into it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2002-09-12 13:28 Message: Logged In: YES user_id=94539 I can fix my particular problem by using packages and not py_modules. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2002-09-12 13:19 Message: Logged In: YES user_id=94539 I read the section loewis linked me to, and the example given there has 'mod1' in the "root package" and "pkg.mod2" in the pkg/ package. This leads me to believe that py_modules do not go into a single package as loewis suggests. In addition, distutils should copy __init__.py files implied by the list of C extension modules. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 03:04 Message: Logged In: YES user_id=21627 It appears that you are misunderstanding the meaning of the py_modules argument. See http://www.python.org/doc/current/dist/setup-script.html#SECTION000320000000000000000 It says "specially the case of a single module that goes in the ``root package'' " All py_modules modules are in a single package, irrespective of their source location. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2002-09-11 16:22 Message: Logged In: YES user_id=94539 I am surprised that sourceforge let me assign this to someone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470 From noreply@sourceforge.net Wed Nov 6 15:14:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 07:14:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) >Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Nov 6 15:14:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 07:14:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-631247 ] Mac OS 10 configure problem Message-ID: Bugs item #631247, was opened at 2002-10-30 22:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631247&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Jack Jansen (jackjansen) Summary: Mac OS 10 configure problem Initial Comment: Using the Python CVS head from about two days ago: Under Mac OS 10 configure --enable-framework; make fails if the source directory is on a NFS mounted disk, but the build directory in a case insensitive Mac volume. According to Jack Jansen this is because configure checks if the source directory is on a file system that is case insensitive, when it should be checking the file system with the build directory: if test -d "${srcdir}/python" then echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 BUILDEXEEXT=.exe else echo "$as_me:$LINENO: result: no" >&5 echo "${ECHO_T}no" >&6 BUILDEXEEXT=$EXEEXT fi ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-11-06 16:14 Message: Logged In: YES user_id=45365 Fixed. Checked in as configure rev. 1.352, configure.in rev. 1.363 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-05 23:11 Message: Logged In: YES user_id=45365 Attaching a patch that I still need to review on a case sensitive system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631247&group_id=5470 From noreply@sourceforge.net Wed Nov 6 15:21:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 07:21:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Nov 6 15:26:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 07:26:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-634246 ] for line in file iterator ignores codecs Message-ID: Bugs item #634246, was opened at 2002-11-06 05:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Aumann (gaumann) Assigned to: M.-A. Lemburg (lemburg) Summary: for line in file iterator ignores codecs Initial Comment: If you use the old file reading idiom with a codec the lines are converted to unicode but if you use the new iterators idiom then they retain the original encoding and are returned in non unicode strings. Using the new "for line in file:" idiom should give the same result as the old, "while 1: ...." I came across this when using the pythonzh Chinese codecs but the below code uses the cp1252 encoding to illustrate the problem because everyone should have those codecs. The symptoms are the same with both codecs. I am using python 2.2.2 on win2k. The following code illustrates the problem: ------------------------------------------------------------------------ """Check readline iterator using a codec.""" import codecs fname = 'tmp.txt' f = file(fname, 'w') for i in range(0x82, 0x8c): f.write( '%x, %s\n' % (i, chr(i))) f.close() def test_iter(): print '\ntesting codec iterator.' f = codecs.open(fname, 'r', 'cp1252') for line in f: l = line.rstrip() print repr(l) print repr(l.decode('cp1252')) f.close() def test_readline(): print '\ntesting codec readline.' f = codecs.open(fname, 'r', 'cp1252') while 1: line = f.readline() if not line: break l = line.rstrip() print repr(l) try: print repr(l.decode('cp1252')) except AttributeError, msg: print 'AttributeError', msg f.close() test_iter() test_readline() ------------------------------------------------------------------------ This code gives the following output: ------------------------------------------------------------------------ testing codec iterator. '82, \x82' u'82, \u201a' '83, \x83' u'83, \u0192' '84, \x84' u'84, \u201e' '85, \x85' u'85, \u2026' '86, \x86' u'86, \u2020' '87, \x87' u'87, \u2021' '88, \x88' u'88, \u02c6' '89, \x89' u'89, \u2030' '8a, \x8a' u'8a, \u0160' '8b, \x8b' u'8b, \u2039' testing codec readline. u'82, \u201a' AttributeError 'unicode' object has no attribute 'decode' u'83, \u0192' AttributeError 'unicode' object has no attribute 'decode' u'84, \u201e' AttributeError 'unicode' object has no attribute 'decode' u'85, \u2026' AttributeError 'unicode' object has no attribute 'decode' u'86, \u2020' AttributeError 'unicode' object has no attribute 'decode' u'87, \u2021' AttributeError 'unicode' object has no attribute 'decode' u'88, \u02c6' AttributeError 'unicode' object has no attribute 'decode' u'89, \u2030' AttributeError 'unicode' object has no attribute 'decode' u'8a, \u0160' AttributeError 'unicode' object has no attribute 'decode' u'8b, \u2039' AttributeError 'unicode' object has no attribute 'decode' ------------------------------------------------------------------------ ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 16:26 Message: Logged In: YES user_id=89016 The problem is that StreamReader and StreamReaderWriter don't have iterator methods, i.e. next() and __iter__() are missing and will be "inherited" from the files via __getattr__. That's why your "for line in f:" works anyway. The attached patch (diff.txt) adds next() and __iter__() to StreamReader and StreamReaderWriter. I don't know what must be done for StreamRecoder. BTW, your decode calls are wrong, because readline *does* return unicode objects, and you can encode unicode objects to str objects or decode str objects into unicode objects. They work in your iterator case, because the fallback iterator implementation from the underlying stream returns str objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 From noreply@sourceforge.net Wed Nov 6 16:00:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 08:00:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Wed Nov 6 16:17:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 08:17:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 17:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 17:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 15:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Wed Nov 6 16:39:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 08:39:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-429357 ] non-greedy regexp duplicating match bug Message-ID: Bugs item #429357, was opened at 2001-06-01 16:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=429357&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Fredrik Lundh (effbot) Summary: non-greedy regexp duplicating match bug Initial Comment: I found some weird bug, where when a non-greedy match doesn't match anything, it will duplicate the rest of the string instead of being None. #pyrebug.py: import re urlrebug=re.compile(""" (.*?):// #scheme ( (.*?) #user (?: :(.*) #pass )? @)? (.*?) #addr (?::([0-9]+))? #port (/.*)?$ #path """, re.VERBOSE) testbad='foo://bah:81/pth' print urlrebug.match(testbad).groups() Bug Output: >python2.1 pyrebug.py ('foo', None, 'bah:81/pth', None, 'bah', '81', '/pth') >python-cvs pyrebug.py ('foo', None, 'bah:81/pth', None, 'bah', '81', '/pth') Good (expected) Output: >python1.5 pyrebug.py ('foo', None, None, None, 'bah', '81', '/pth') ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-06 16:39 Message: Logged In: YES user_id=7887 This problem was fixed in the following CVS revisions: Lib/test/re_tests.py:1.30->1.31 Lib/test/test_sre.py:1.37->1.38 Misc/NEWS:1.511->1.512 Modules/_sre.c:2.83->2.84 Thank you! ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-10-05 04:16 Message: Logged In: YES user_id=65253 Ok, after poking and prodding the _sre.c code a bunch until I (hopefully) understand what is happening, I've created a patch. It passes all existing re tests as well as new ones I added for this bug. (I've also made a patch for the similar, but seperate, bug #448951 which I will post there shortly.) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2001-08-30 16:26 Message: Logged In: YES user_id=292741 This looks like the same bug I have reported (with a much simpler example) as #448951 (missed this one before because I was looking for 'group'). What I found is consistent with Jeffrey's comments - if you have a situation where an optional part is fully scanned before the state machine can tell if it should actually be matched, the contained tentative match(es) are stored in the group() even if the optional part turns out to fail. Presumably, such a case needs to be handled by going back and deleting these after the s.m. determines that the optional part was not matched. In my example, I mention a small modification to the test case where the failure of the optional ? is decided one character later (at the end of the () group, not beyond it); this is enough to make it start working again. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-06-14 07:59 Message: Logged In: YES user_id=65253 I think I understand what you are saying, and in the context of the test, it doesn't seem too bad. BUT, my original code (and what I'd like to have) did not have the surrounding group. So I'd just get: ('foo', 'bah:81/pth', None, 'bah', '81', '/pth') Knowing the general ease of messing up regexs when writing them, I'm sure you can image the pain I went through before actually realizing it was a python bug :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-13 17:12 Message: Logged In: NO What's happening makes sense, on one level. When the regex engine gets to the user:pass@ part ((.*?)(?::(.*))?@)? which fill groups 2, 3, and 4, the .*? of group 3 has to try at every character in the rest of the string before admitting overall defeat. In doing that, the last time that group 3 successfully completely locally, it has the rest of the string matched. Of course, overall, group three is enclosed within group 2, and when group two couldn't complete successfully, the engine knows it can skip group two (due to the ? modifying it), so it totally bails on groups 2, 3 and 4 to continue with the rest of the expression. What you'd like to happen is when that "bailing" happens for group 2, the enclosing groups 3 and 4 would get zereoed out (since they didn't participate in the *final* overall match). That makes sense, and is what I would expect to happen. However, what *is* happening is that group 3 is keeping the string that *it* last matched (even thought that last match didn't contribute to the final, overall match). I'm not explaining this well -- I hope you can understand it despite that. Sorry. Jeffrey ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=429357&group_id=5470 From noreply@sourceforge.net Wed Nov 6 16:39:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 08:39:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-634246 ] for line in file iterator ignores codecs Message-ID: Bugs item #634246, was opened at 2002-11-06 05:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Aumann (gaumann) >Assigned to: Walter Dörwald (doerwalter) Summary: for line in file iterator ignores codecs Initial Comment: If you use the old file reading idiom with a codec the lines are converted to unicode but if you use the new iterators idiom then they retain the original encoding and are returned in non unicode strings. Using the new "for line in file:" idiom should give the same result as the old, "while 1: ...." I came across this when using the pythonzh Chinese codecs but the below code uses the cp1252 encoding to illustrate the problem because everyone should have those codecs. The symptoms are the same with both codecs. I am using python 2.2.2 on win2k. The following code illustrates the problem: ------------------------------------------------------------------------ """Check readline iterator using a codec.""" import codecs fname = 'tmp.txt' f = file(fname, 'w') for i in range(0x82, 0x8c): f.write( '%x, %s\n' % (i, chr(i))) f.close() def test_iter(): print '\ntesting codec iterator.' f = codecs.open(fname, 'r', 'cp1252') for line in f: l = line.rstrip() print repr(l) print repr(l.decode('cp1252')) f.close() def test_readline(): print '\ntesting codec readline.' f = codecs.open(fname, 'r', 'cp1252') while 1: line = f.readline() if not line: break l = line.rstrip() print repr(l) try: print repr(l.decode('cp1252')) except AttributeError, msg: print 'AttributeError', msg f.close() test_iter() test_readline() ------------------------------------------------------------------------ This code gives the following output: ------------------------------------------------------------------------ testing codec iterator. '82, \x82' u'82, \u201a' '83, \x83' u'83, \u0192' '84, \x84' u'84, \u201e' '85, \x85' u'85, \u2026' '86, \x86' u'86, \u2020' '87, \x87' u'87, \u2021' '88, \x88' u'88, \u02c6' '89, \x89' u'89, \u2030' '8a, \x8a' u'8a, \u0160' '8b, \x8b' u'8b, \u2039' testing codec readline. u'82, \u201a' AttributeError 'unicode' object has no attribute 'decode' u'83, \u0192' AttributeError 'unicode' object has no attribute 'decode' u'84, \u201e' AttributeError 'unicode' object has no attribute 'decode' u'85, \u2026' AttributeError 'unicode' object has no attribute 'decode' u'86, \u2020' AttributeError 'unicode' object has no attribute 'decode' u'87, \u2021' AttributeError 'unicode' object has no attribute 'decode' u'88, \u02c6' AttributeError 'unicode' object has no attribute 'decode' u'89, \u2030' AttributeError 'unicode' object has no attribute 'decode' u'8a, \u0160' AttributeError 'unicode' object has no attribute 'decode' u'8b, \u2039' AttributeError 'unicode' object has no attribute 'decode' ------------------------------------------------------------------------ ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-06 17:39 Message: Logged In: YES user_id=38388 Walter, the patch looks good. Please check it in. A patch for StreamRecoder should look the same since that's how file iterators should work (ie. return a complete line in each iteration). Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 16:26 Message: Logged In: YES user_id=89016 The problem is that StreamReader and StreamReaderWriter don't have iterator methods, i.e. next() and __iter__() are missing and will be "inherited" from the files via __getattr__. That's why your "for line in f:" works anyway. The attached patch (diff.txt) adds next() and __iter__() to StreamReader and StreamReaderWriter. I don't know what must be done for StreamRecoder. BTW, your decode calls are wrong, because readline *does* return unicode objects, and you can encode unicode objects to str objects or decode str objects into unicode objects. They work in your iterator case, because the fallback iterator implementation from the underlying stream returns str objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 From noreply@sourceforge.net Wed Nov 6 16:54:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 08:54:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-634246 ] for line in file iterator ignores codecs Message-ID: Bugs item #634246, was opened at 2002-11-06 05:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 Category: Unicode Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Aumann (gaumann) Assigned to: Walter Dörwald (doerwalter) Summary: for line in file iterator ignores codecs Initial Comment: If you use the old file reading idiom with a codec the lines are converted to unicode but if you use the new iterators idiom then they retain the original encoding and are returned in non unicode strings. Using the new "for line in file:" idiom should give the same result as the old, "while 1: ...." I came across this when using the pythonzh Chinese codecs but the below code uses the cp1252 encoding to illustrate the problem because everyone should have those codecs. The symptoms are the same with both codecs. I am using python 2.2.2 on win2k. The following code illustrates the problem: ------------------------------------------------------------------------ """Check readline iterator using a codec.""" import codecs fname = 'tmp.txt' f = file(fname, 'w') for i in range(0x82, 0x8c): f.write( '%x, %s\n' % (i, chr(i))) f.close() def test_iter(): print '\ntesting codec iterator.' f = codecs.open(fname, 'r', 'cp1252') for line in f: l = line.rstrip() print repr(l) print repr(l.decode('cp1252')) f.close() def test_readline(): print '\ntesting codec readline.' f = codecs.open(fname, 'r', 'cp1252') while 1: line = f.readline() if not line: break l = line.rstrip() print repr(l) try: print repr(l.decode('cp1252')) except AttributeError, msg: print 'AttributeError', msg f.close() test_iter() test_readline() ------------------------------------------------------------------------ This code gives the following output: ------------------------------------------------------------------------ testing codec iterator. '82, \x82' u'82, \u201a' '83, \x83' u'83, \u0192' '84, \x84' u'84, \u201e' '85, \x85' u'85, \u2026' '86, \x86' u'86, \u2020' '87, \x87' u'87, \u2021' '88, \x88' u'88, \u02c6' '89, \x89' u'89, \u2030' '8a, \x8a' u'8a, \u0160' '8b, \x8b' u'8b, \u2039' testing codec readline. u'82, \u201a' AttributeError 'unicode' object has no attribute 'decode' u'83, \u0192' AttributeError 'unicode' object has no attribute 'decode' u'84, \u201e' AttributeError 'unicode' object has no attribute 'decode' u'85, \u2026' AttributeError 'unicode' object has no attribute 'decode' u'86, \u2020' AttributeError 'unicode' object has no attribute 'decode' u'87, \u2021' AttributeError 'unicode' object has no attribute 'decode' u'88, \u02c6' AttributeError 'unicode' object has no attribute 'decode' u'89, \u2030' AttributeError 'unicode' object has no attribute 'decode' u'8a, \u0160' AttributeError 'unicode' object has no attribute 'decode' u'8b, \u2039' AttributeError 'unicode' object has no attribute 'decode' ------------------------------------------------------------------------ ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 17:54 Message: Logged In: YES user_id=89016 Checked in as: Misc/NEWS 1.513 Lib/codecs.py 1.28 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-06 17:39 Message: Logged In: YES user_id=38388 Walter, the patch looks good. Please check it in. A patch for StreamRecoder should look the same since that's how file iterators should work (ie. return a complete line in each iteration). Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 16:26 Message: Logged In: YES user_id=89016 The problem is that StreamReader and StreamReaderWriter don't have iterator methods, i.e. next() and __iter__() are missing and will be "inherited" from the files via __getattr__. That's why your "for line in f:" works anyway. The attached patch (diff.txt) adds next() and __iter__() to StreamReader and StreamReaderWriter. I don't know what must be done for StreamRecoder. BTW, your decode calls are wrong, because readline *does* return unicode objects, and you can encode unicode objects to str objects or decode str objects into unicode objects. They work in your iterator case, because the fallback iterator implementation from the underlying stream returns str objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634246&group_id=5470 From noreply@sourceforge.net Wed Nov 6 18:09:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 10:09:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-522780 ] bsddb keys corruption Message-ID: Bugs item #522780, was opened at 2002-02-26 02:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=522780&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Marc Conley (mconley) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb keys corruption Initial Comment: I'm having a problem with either the keys() function returning invalid information or the database getting corrupted or something along those lines. This is what I keep seeing occasionally during my development: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> db = bsddb.hashopen("test.db") >>> db.keys() ['192.168.0.1799'] >>> db["192.168.0.1799"] Traceback (most recent call last): File "", line 1, in ? KeyError: 192.168.0.1799 >>> The lines of importance are the return value for db.keys() and then the traceback. Note that the db.keys () returns a value that I immediately try to access and get a KeyError in so doing. This happens in a program with multiple threads but for which I am using a threading.Lock acquire() and release() around all database/bsddb accesses. I am also using sync()s after all write operations. The key value, by the way, should be 192.168.0.179. It is consistently, on several different occasions, getting the extra "9" appended to the end of it. This same problem has occurred 3 times during testing. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-06 18:09 Message: Logged In: YES user_id=7887 Marc, could you please provide a testcase, as stated below? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-10 11:42 Message: Logged In: YES user_id=539787 What does the following produce as output in the above example? >>> db[db.keys()[0]] If that fails, you most surely have key corruption. If not, then please come back with a standalone script that displays erratic behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=522780&group_id=5470 From noreply@sourceforge.net Wed Nov 6 18:29:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 10:29:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 13:29 Message: Logged In: YES user_id=11375 I'd like to add my vote for bumping up the priority of this patch; two people have run into this so far. ---------------------------------------------------------------------- Comment By: Bill Noon (bnoon) Date: 2002-11-01 15:18 Message: Logged In: YES user_id=298547 I just used the patch to fix problems with Quixote. Seems to have done the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-10 05:38 Message: Logged In: YES user_id=6656 Ah good. Will wait for your comments. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 18:27 Message: Logged In: YES user_id=31392 I'm listening, but it's going in one ear and out the other. I hope to have time for this later in the week. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 08:54 Message: Logged In: YES user_id=6656 Here's a patch that lets me compile the standard library and test suite with the compiler package and then run the test suite successfully. It does... oh, lots and lots of stuff. Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 06:08 Message: Logged In: YES user_id=6656 Here's a patch. Remarkably, it's just a one line patch to work around the SET_LINENO breakage. Other changes: * open the file for compiling in universal newlines mode. * always write the mtime to a .pyc little-endian-wise (2.2.2 candidate) * it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate) * bodge the parsermodule to return the encoding along with the encoding_decl non-terminal (this is pretty icky!) * let transformer cope with new 'testlist1' non-terminal * have transformer pick up the encoding declaration Still to do is using the encoding declaration to decode string literals. I think there should be an accessible from Python function to do this -- I really don't want to have to translate compile.c:parsestr into Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 05:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 11:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 05:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 12:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 05:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Wed Nov 6 18:33:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 10:33:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 13:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 11:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Wed Nov 6 18:47:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 10:47:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-466200 ] ability to specify a 'verify' script Message-ID: Bugs item #466200, was opened at 2001-09-28 21:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 Category: Distutils Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: A.M. Kuchling (akuchling) Summary: ability to specify a 'verify' script Initial Comment: The following patch adds the ability to specify a 'verify' script (as used by the %verify). Treatment is exactly the same as with post_install, etc... --- bdist_rpm.py Wed Sep 12 11:42:17 2001 +++ /home/agamemnon/jnelson/bdist_rpm.py Fri Sep 28 16:09:18 2001 @@ -131,6 +131,7 @@ self.post_install = None self.pre_uninstall = None self.post_uninstall = None + self.verifyscript = None self.prep = None self.provides = None self.requires = None @@ -210,6 +211,7 @@ self.ensure_filename('post_install') self.ensure_filename('pre_uninstall') self.ensure_filename('post_uninstall') + self.ensure_filename('verifyscript') # XXX don't forget we punted on summaries and descriptions -- they # should be handled here eventually! @@ -423,6 +425,7 @@ ('post', 'post_install', None), ('preun', 'pre_uninstall', None), ('postun', 'post_uninstall', None), + ('verify', 'verifyscript', None), ] for (rpm_opt, attr, default) in script_options: ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-06 18:47 Message: Logged In: YES user_id=7887 Applied in the following CVS revisions: Lib/distutils/command/bdist_rpm.py: 1.33->1.34 Misc/NEWS: 1.513->1.514 I've done a few changes to your original patch: - Named the option verify_script, for conformance with other options (clean_script, etc). - The rpm section is named "%verifyscript", not "%verify". I've reflected that in the script_options tuple. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=466200&group_id=5470 From noreply@sourceforge.net Wed Nov 6 22:00:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 14:00:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 22:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 23:00 Message: Logged In: YES user_id=21627 This is fixed in Makefile.pre.in 1.101 NEWS 1.515 setup.py 1.4 IDLE is now installed automatically unless _tkinter cannot be imported. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-06 14:22 Message: Logged In: YES user_id=45365 Alternatively, only install Idle if Tkinter works. This is what Mac/OSX/Makefile does for both Idle and IDE: they're only installed if the prerequisite modules work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:57 Message: Logged In: YES user_id=21627 Nothing is wrong with installing IDLE. On the particular distro, IDLE may have come from a separate RPM, though: IDLE depends on Tkinter, which depends on Tcl/Tk, which depends on X11. So installing IDLE has more prerequisites than installing Python itself. That's why distros like to split Tkinter, and subsequently IDLE, into a separate package, so you can install Python without installing X11. All I'm asking is that install-idle is a separate sub-target, so that you *can* install Python without installing IDLE. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:31 Message: Logged In: YES user_id=6380 Actually, I believe I've seen a Linux distro that had idle installed. And what's wrong with installing idle? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:24 Message: Logged In: YES user_id=21627 Maybe. This would be a deviation from the past, so I'm sure users will be surprised if 'make install' does that. For people building binary distributions, there probably needs to be a target that does the traditional install only, or they need to invoke altinstall bininstall maninstall but not idleinstall. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 23:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Wed Nov 6 22:13:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 14:13:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 15:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 23:13 Message: Logged In: YES user_id=21627 On what version of OpenBSD does that happen? Also, can you find out why _XOPEN_SOURCE is not defined when testing for makedev? configure ought to define it while running the tests, and does that on my system. To be certain, you can add a line cp confdefs.h foo.h immediately before the test for makedev is run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Wed Nov 6 22:17:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 14:17:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-436131 ] freeze: global symbols not exported Message-ID: Bugs item #436131, was opened at 2001-06-25 17:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=436131&group_id=5470 Category: Demos and Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Charles Schwieters (chuckorama) Assigned to: Mark Hammond (mhammond) Summary: freeze: global symbols not exported Initial Comment: python-2.1 linux-2.2, others? the freeze tool does not export global symbols. As a result the frozen executable fails with unresolved symbols in shared objects. fix: include the LINKFORSHARED flag in freeze.py: *** freeze.py~ Tue Mar 20 15:43:33 2001 --- freeze.py Fri Jun 22 14:36:23 2001 *************** *** 434,440 **** somevars[key] = makevars[key] somevars['CFLAGS'] = string.join(cflags) # override ! files = ['$(OPT)', '$(LDFLAGS)', base_config_c, base_frozen_c] + \ files + supp_sources + addfiles + libs + \ ['$(MODLIBS)', '$(LIBS)', '$(SYSLIBS)'] --- 434,440 ---- somevars[key] = makevars[key] somevars['CFLAGS'] = string.join(cflags) # override ! files = ['$(OPT)', '$(LDFLAGS)', '$(LINKFORSHARED)',base_config_c, base_frozen_c] + \ files + supp_sources + addfiles + libs + \ ['$(MODLIBS)', '$(LIBS)', '$(SYSLIBS)'] ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-06 22:17 Message: Logged In: YES user_id=7887 Thanks for reporting. This problem is already fixed in the CVS. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 00:18 Message: Logged In: YES user_id=33168 Is there a test case I can use to trigger this error? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-15 23:47 Message: Logged In: YES user_id=14198 This seems to have bene found on Linux. While the patch looks reasonable to me, I am not in a position to test. Can anyone else with a Unix background tell me this seems reasonable? ---------------------------------------------------------------------- Comment By: Jens Krinke (krinke) Date: 2002-02-21 12:39 Message: Logged In: YES user_id=345110 I think this patch will fix most of the "freeze fails" reports and requests in newsgroups. The bug itself is still in 2.2 and 2.1.2 :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=436131&group_id=5470 From noreply@sourceforge.net Wed Nov 6 23:02:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 15:02:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-634422 ] global name 'name' is not defined Message-ID: Bugs item #634422, was opened at 2002-11-06 08:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634422&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Martin v. Löwis (loewis) >Assigned to: A.M. Kuchling (akuchling) Summary: global name 'name' is not defined Initial Comment: It appears rev. 1.36 introduced a new error, I get File "/usr/local/lib/python2.3/urllib2.py", line 324, in open '_open', req) File "/usr/local/lib/python2.3/urllib2.py", line 303, in _call_chain result = func(*args) File "/usr/local/lib/python2.3/urllib2.py", line 793, in http_open return self.do_open(httplib.HTTP, req) File "/usr/local/lib/python2.3/urllib2.py", line 774, in do_open if name not in req.headers: NameError: global name 'name' is not defined ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-06 18:02 Message: Logged In: YES user_id=33168 amk checked in 1.38 to fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634422&group_id=5470 From noreply@sourceforge.net Wed Nov 6 23:04:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 15:04:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-634078 ] Need to install IDLE Message-ID: Bugs item #634078, was opened at 2002-11-05 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need to install IDLE Initial Comment: On Windows, IDLE is installed in the start menu, but on Unix, it is not installed at all. It would be nice if it was invokable simply by typing idle in the shell. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 18:04 Message: Logged In: YES user_id=6380 Cool! Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 17:00 Message: Logged In: YES user_id=21627 This is fixed in Makefile.pre.in 1.101 NEWS 1.515 setup.py 1.4 IDLE is now installed automatically unless _tkinter cannot be imported. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-06 08:22 Message: Logged In: YES user_id=45365 Alternatively, only install Idle if Tkinter works. This is what Mac/OSX/Makefile does for both Idle and IDE: they're only installed if the prerequisite modules work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 17:57 Message: Logged In: YES user_id=21627 Nothing is wrong with installing IDLE. On the particular distro, IDLE may have come from a separate RPM, though: IDLE depends on Tkinter, which depends on Tcl/Tk, which depends on X11. So installing IDLE has more prerequisites than installing Python itself. That's why distros like to split Tkinter, and subsequently IDLE, into a separate package, so you can install Python without installing X11. All I'm asking is that install-idle is a separate sub-target, so that you *can* install Python without installing IDLE. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 17:31 Message: Logged In: YES user_id=6380 Actually, I believe I've seen a Linux distro that had idle installed. And what's wrong with installing idle? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 17:24 Message: Logged In: YES user_id=21627 Maybe. This would be a deviation from the past, so I'm sure users will be surprised if 'make install' does that. For people building binary distributions, there probably needs to be a target that does the traditional install only, or they need to invoke altinstall bininstall maninstall but not idleinstall. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 17:16 Message: Logged In: YES user_id=6380 Maybe "make install" should do this then? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 17:14 Message: Logged In: YES user_id=21627 Notice that there is a working distutils configuration for idle. Just do 'python setup.py install', and you get an idle executable in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634078&group_id=5470 From noreply@sourceforge.net Wed Nov 6 23:32:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 15:32:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-06 23:32 Message: Logged In: YES user_id=76089 I am using OpenBSD 2.7, but I think the very latest OpenBSD is just the same. I have investigated a bit more and you are right that _XOPEN_SOURCE is defined during configure. I *think* the problem is that the configure test used to detect HAVE_DEVICE_MACROS is broken. It is just trying to compile, but not link, "makedev(major(0),minor(0))", and it is not an error to try and compile that line even if makedev, major and minor are not defined since the compiler assumes they are unknown functions returning int. It is only an error at link time, and the configure test does not try to link the test code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 22:13 Message: Logged In: YES user_id=21627 On what version of OpenBSD does that happen? Also, can you find out why _XOPEN_SOURCE is not defined when testing for makedev? configure ought to define it while running the tests, and does that on my system. To be certain, you can add a line cp confdefs.h foo.h immediately before the test for makedev is run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Thu Nov 7 03:30:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 19:30:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-581080 ] Provoking infinite scanner loops Message-ID: Bugs item #581080, was opened at 2002-07-13 19:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581080&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fredrik Lundh (effbot) Summary: Provoking infinite scanner loops Initial Comment: >From c.l.py: """ From: Jane Austine Sent: Saturday, July 13, 2002 6:01 AM To: python-list@python.org Subject: sre.finditer break down: is this a bug? Newly added function sre.finditer and (matchedObject.)finditer break down and the system crushes on win32 when requested for next() after StopIteration. see: >> import sre >> fi=sre.finditer(r'\s','a b') >> fi.next() >> fi.next() >> fi.next() #system halts for ever. -- """ The semantics of the underlying calliterobject aren't clear to me in this endcase, and I've raised that issue on c.l.py. But regardless of how that's resolved, it's easy to provoke the bad behavior without using finditer, and that should be fixed: >>> import re >>> s = re.compile(r'\s').scanner >>> t = s('a b').search >>> t() <_sre.SRE_Match object at 0x00679F70> >>> t() >>> t() >>> t() and there it's hung. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-07 03:30 Message: Logged In: YES user_id=7887 Fixed in the following CVS revisions: Misc/NEWS: 1.515->1.516 Modules/_sre.c: 2.84->2.85 Thank you, Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-13 19:35 Message: Logged In: YES user_id=31435 Oops -- I meant I raised the calliterobject issue on Python- Dev, not on c.l.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581080&group_id=5470 From noreply@sourceforge.net Thu Nov 7 06:22:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 22:22:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-634069 ] Errors in ** docs Message-ID: Bugs item #634069, was opened at 2002-11-05 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Raymond Hettinger (rhettinger) Summary: Errors in ** docs Initial Comment: Section 5.4 "The power operator" is out of date: 1. Raising a postive int to a negative int power no longer raises TypeError (it returns a float). 2. It's unclear what "a broken power" means. Raising a negative float to a non-integer power raises ValueError (not TypeError), if that's what it means. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 From noreply@sourceforge.net Thu Nov 7 06:58:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 22:58:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-634069 ] Errors in ** docs Message-ID: Bugs item #634069, was opened at 2002-11-05 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 Category: Documentation >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Errors in ** docs Initial Comment: Section 5.4 "The power operator" is out of date: 1. Raising a postive int to a negative int power no longer raises TypeError (it returns a float). 2. It's unclear what "a broken power" means. Raising a negative float to a non-integer power raises ValueError (not TypeError), if that's what it means. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 01:58 Message: Logged In: YES user_id=80475 Tim, how does this patch look to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 From noreply@sourceforge.net Thu Nov 7 07:43:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Nov 2002 23:43:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 15:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 08:43 Message: Logged In: YES user_id=21627 Ok, I have now changed configure to link the test program, in configure 1.353, configure.in 1.364. Can you please confirm that this solves the problem? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-07 00:32 Message: Logged In: YES user_id=76089 I am using OpenBSD 2.7, but I think the very latest OpenBSD is just the same. I have investigated a bit more and you are right that _XOPEN_SOURCE is defined during configure. I *think* the problem is that the configure test used to detect HAVE_DEVICE_MACROS is broken. It is just trying to compile, but not link, "makedev(major(0),minor(0))", and it is not an error to try and compile that line even if makedev, major and minor are not defined since the compiler assumes they are unknown functions returning int. It is only an error at link time, and the configure test does not try to link the test code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 23:13 Message: Logged In: YES user_id=21627 On what version of OpenBSD does that happen? Also, can you find out why _XOPEN_SOURCE is not defined when testing for makedev? configure ought to define it while running the tests, and does that on my system. To be certain, you can add a line cp confdefs.h foo.h immediately before the test for makedev is run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Thu Nov 7 09:22:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 01:22:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 22:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 09:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 22:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 21:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 07:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 19:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 04:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Thu Nov 7 10:11:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 02:11:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Thu Nov 7 10:56:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 02:56:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-634905 ] segfault unpickling Numeric 'O' array Message-ID: Bugs item #634905, was opened at 2002-11-07 10:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634905&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raik Gruenberg (graik) Assigned to: Nobody/Anonymous (nobody) Summary: segfault unpickling Numeric 'O' array Initial Comment: A numpy array of objects can only be unpickled in the same Python interpreter where it was pickled. Otherwise a segmentation fault occurs when the unpickled array is first accessed. Python version: all tested (2.1 and 2.2 and 2.2.1) OS: all tested (Linux rh 7.1 and 7.3, MacOSX) Numeric version: 22 EXAMPLE: ------------- import sys from Numeric import * import cPickle list = [{'name':'A', 'x':1}, {'name':'B', 'x':2}] mask = [1,1] rlist = compress( mask, list ) ## rlist = rlist.tolist() ## work-around f = open( 'r.dat', 'w' ) r = cPickle.dump( rlist, f, 0) ## same with bin=1 or pickle.dump f.close() sys.exit(0) ## RESTART PYTHON INTERPRETER HERE ## (otherwise no segFault) import cPickle f = open( 'r.dat') r = cPickle.load(f) ## same with pickle.load f.close() ## causes SEGFAULT: print r ---------- The bug could probably also be submitted to the Numeric team. Greetings Raik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634905&group_id=5470 From noreply@sourceforge.net Thu Nov 7 13:08:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 05:08:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-634905 ] segfault unpickling Numeric 'O' array Message-ID: Bugs item #634905, was opened at 2002-11-07 11:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634905&group_id=5470 Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Raik Gruenberg (graik) Assigned to: Nobody/Anonymous (nobody) Summary: segfault unpickling Numeric 'O' array Initial Comment: A numpy array of objects can only be unpickled in the same Python interpreter where it was pickled. Otherwise a segmentation fault occurs when the unpickled array is first accessed. Python version: all tested (2.1 and 2.2 and 2.2.1) OS: all tested (Linux rh 7.1 and 7.3, MacOSX) Numeric version: 22 EXAMPLE: ------------- import sys from Numeric import * import cPickle list = [{'name':'A', 'x':1}, {'name':'B', 'x':2}] mask = [1,1] rlist = compress( mask, list ) ## rlist = rlist.tolist() ## work-around f = open( 'r.dat', 'w' ) r = cPickle.dump( rlist, f, 0) ## same with bin=1 or pickle.dump f.close() sys.exit(0) ## RESTART PYTHON INTERPRETER HERE ## (otherwise no segFault) import cPickle f = open( 'r.dat') r = cPickle.load(f) ## same with pickle.load f.close() ## causes SEGFAULT: print r ---------- The bug could probably also be submitted to the Numeric team. Greetings Raik ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 14:08 Message: Logged In: YES user_id=21627 This is not a bug in Python. pickle eventually executes from Numeric import array_constructor print array_constructor((2,), 'O', '\x00\x18\xa2P\x00\x18\xa2\xe8', 0) Numeric fails to return a sensible object for that call, so this is clearly a bug in Numeric. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634905&group_id=5470 From noreply@sourceforge.net Thu Nov 7 14:49:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 06:49:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-564729 ] FixTk.py logic wrong Message-ID: Bugs item #564729, was opened at 2002-06-05 02:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470 Category: Tkinter Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) >Assigned to: Martin v. Löwis (loewis) Summary: FixTk.py logic wrong Initial Comment: The logic in FixTk.py is wrong for Tix: the Tix version number is independent of the Tk/Tcl version number. Just duplicate the Tcl code logic for Tix, and don't reuse the Tcl version number. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 09:49 Message: Logged In: YES user_id=6380 Randomly assigned to Martin. Martin, can you do this? If not, assign it back to me. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 00:06 Message: Logged In: YES user_id=33229 Sorry for the lack of detail: the logic is wrong because the version number of Tix is assumed to be the same as the version number of Tcl in _tkinter. Right now they are different (8.3 or 8.4 for Tcl and 8.1 for Tix) and in general these days with stubs in Tcl, they are unrelated. Any Tix should work with any Tcl after Tcl 8.1 or so. So the answer is to remove tix from the for loop, and just copy the Tcl block of logic and change the tcl to tix as in the following (untested) if not os.environ.has_key("TIX_LIBRARY"): for name in os.listdir(prefix): if name.startswith("tix"): tixdir = os.path.join(prefix,name) if os.path.isdir(tixdir): os.environ["TIX_LIBRARY"] = tixdir del tixdir Note that as it stands now there is a subtle difference between the logic for setting TCL_LIBRARY and for setting TK_LIBRARY (ignoring tix completely). Imagine you have a Tcl directory with no environment variables and the following subdirs: tcl8.3 tcl8.4 tk8.3 tk8.4 If os.listddir returns the directories in alphabetical order I think you end up with TCL_LIBRARY=.../tcl8.4 (there's no break in the for name loop) and TK_LIBRARY=.../tk8.3 if tk was compiled with tcl 8.3 (_tkinter.TCL_VERSION) With Tk8.4 now finally released this a real potential scenario. This may be good or bad - the attached file maintains it. The discussion above and the attached file applies to all versions of Python, so it should be tagged for any 2.x branch. I think the same is true for Tix.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 15:25 Message: Logged In: YES user_id=6380 Can you please supply a patch? The code in 2.2 and later is different; is that still broken? If so, please supply two patches! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470 From noreply@sourceforge.net Thu Nov 7 14:52:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 06:52:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 07:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 09:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 02:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 00:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 22:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-09 20:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 08:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 07:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 07:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 06:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 14:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply@sourceforge.net Thu Nov 7 14:58:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 06:58:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown Message-ID: Bugs item #231207, was opened at 2001-02-05 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Henderson (djhender) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python Error during program shutdown Initial Comment: The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a event or call to a ?.destory() function. Under Windows 98SE, this results in a GPF. Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate". The following script demonstrates the problem: --------------------- # BugDemo.py from Tkinter import * class BugDemo(Frame): def __init__(self, parent): Frame.__init__(self, parent) Button(self, text='Hi', command=self.hi).pack() Button(self, text='Quit', command=self.tk.quit).pack() def hi(self): print "hi" bd = BugDemo(Tk()) bd.pack() bd.mainloop() ---------------------- Execute in console window: "c:> python BugDemo.py" Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button. Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly. Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time. The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem. Problem also manifests using the PythonWare 2.0 release on Win98. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 09:58 Message: Logged In: YES user_id=6380 idiscovery, when you say "PythonWin" do you actually mean Pythonwin (a Win32-specific Python IDE, part of Mark Hammond's win32all)? Or do you simple mean "Python under Windows", as installed by the Python installer you get from python.org? This difference is significant; I would not expect Tkinter apps to work well using Pythonwin, because it has its own Win32 event loop. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2002-11-04 13:12 Message: Logged In: YES user_id=148444 I modified my BugDemo program to change the last 3 lines to root = Tk() bd = BugDemo(root) bd.pack() bd.mainloop() root.destory() This did not resolve the problem under Win98SE Python 2.2.1. Both Python 2.2.1 and 2.2.2 use Tk/tcl 8.3. I have seen comments that indicate that this is a known problem in stock 8.3 which is fixed in 8.4. I also tested using the other two scripts presented elsewhere among the comments to this bug report. These tests also hang, even with the added root.destroy() statement. I no longer have access to a Win2k machine, so I cannot test there. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 01:52 Message: Logged In: YES user_id=33229 I know I'm a Python newbie but I know Tcl well and I think I know at least part of what's going on. Looking specifically at nobody's 2002-04-22 14:21 code, I see that this uses mainloop and quit in a way that many Python books and examples do, as if quit() will "Quit the Tcl interpreter. All widgets will be destroyed." But if you look at MainLoop and Quit in _tkinter.c you see that Quit just sets a variable that causes MainLoop to end - it doesn't destroy anything nor quit the interpreter. IMHO all Tkinter programs need a root.destroy() after root.mainloop() If you change nobody's program to add a root.destroy() it runs fine under PythonWin. The "bug" is in the documentation of quit() in Tkinter.py def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self.tk.quit() The comment should read """Quit the main event loop. It is up to you to call root.destroy() after.""" If I'm right the documentation for Tkinter in the library reference should be changed too; there should be a root.destroy() at the end of http://www.python.org/doc/2.2.1/lib/node503.html If I'm right then I'll stick my neck out a little further: Tkinter's mainloop and quit should be dropped from _tkinter.c and replaced with the following idiom and usage: In Tkinter.py declare a class variable in Misc: _exit = -1 and change in Misc TCL_ALL_EVENTS = 0 def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self._exit = 0 def mainloop(self): """Loop until we call quit()""" while self._exit < 0: try: self.root.tk.dooneevent(TCL_ALL_EVENTS) except SystemExit: #print 'Exit' self.exit = 1 break except # do something intelligent with errors or interrupts I believe this is more transparent and more open to creativity. I have experimented (all my code is like this now) and feel that there is no performance penalty to looping in Python. In addition it avoids the 20msec sleep in _tkinter.mainloop() that is an abomination. It would also allow people to think more clearly about what happens when you have 2 Tk() instances, in which case you have 2 Tcl interpeters. It may make you move _exit to be an instance variable of the Tk class. In any event you'll be able to see what's going on. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 10:21 Message: Logged In: NO I confirm the behaviour for: WinNT 4.0 SP5 tested with Python 2.2Beta1 (ActiveState) tested with Python 2.2.1.222 (ActiveState) PythonWinIDE will hang when the following program is "quit"ted. But will "quit" normally when run standalone (not within PythonWinIDE): # # from Tkinter import * from tkMessageBox import * class App: def __init__(self, winRoot): frame = Frame(winRoot) frame.pack() self.btnQuit = Button(frame, text="QUIT", bg="blue", foreground="light blue", command=frame.quit) self.btnQuit.pack(side=LEFT) self.btnHiThere = Button(frame, text="Hi there!",command=self.sayHiThere) self.btnHiThere.pack(side=LEFT) def sayHiThere(self): showinfo("Greeting", "Hi There") if __name__ == "__main__": root = Tk() test = App(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 17:49 Message: Logged In: YES user_id=31392 Unassign as it appears that effbot isn't going to look at it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-18 07:13 Message: Logged In: NO i won't to be a hacker ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-29 03:30 Message: Logged In: NO Note: I am running Windows98 ActivePython 2.1 Even with console apps in python this same error appears I tried using another Distribution of Python for win32, PythonWare20 So this leads me to believe that some lib is missing on win98. Because at work I use Win95, and Installed ActivePython 2.1, and it works fine and dandy ---------------------------------------------------------------------- Comment By: Joel Gould (joelgould) Date: 2001-03-24 11:52 Message: Logged In: YES user_id=20954 I also see a GPF on shutdown under Windows 98 using Tkinter. I tested this using the PythonWare 2.0 release as well. I have attached a very simple Tkinter program. When I run this on my Windows 98 SE machine, a crash occurs when the program exits. Without the MainDialog class it works OK. Without the Pmw initialization call it works OK. But as written it will crash around 75% of the time. (1) run the program (2) press the Test Button (3) click Cancel in the file open dialog (you do not need to select a file) (4) click the close button in the upper right corner --> Boom -------------------- import Tkinter import tkFileDialog import Pmw def action(): tkFileDialog.askopenfilename(filetypes=[('All','*')]) class MainDialog: def __init__(self,parent): Tkinter.Button(parent,text='Test Button',command=action).pack() root = Pmw.initialise() dialog = MainDialog(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-09 18:34 Message: Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-06 00:30 Message: See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 From noreply@sourceforge.net Thu Nov 7 15:00:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 07:00:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit Message-ID: Bugs item #453489, was opened at 2001-08-20 16:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using deiconify() hangs on exit Initial Comment: If you run the following script, and iconize the window before the after() timer, it'll restore and raise the window as it should, but then you can't exit. You have to kill winoldap with ctrl+alt+del and wait. I ran into this trying to write a portable jabber client using tkinter. This is with 2.1.1 on Windows 98. Does it every time. May be related to bug #216289. from Tkinter import * import sys def foo(): print 'foo' sys.stdout.flush() root.deiconify() print 'bar' sys.stdout.flush() root=Tk() Button(root, text='Quit', command=root.quit).pack() root.after(5000, foo) root.mainloop() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 10:00 Message: Logged In: YES user_id=6380 idiscovery, when you say "PythonWin" do you actually mean Pythonwin (a Win32-specific Python IDE, part of Mark Hammond's win32all)? Or do you simple mean "Python under Windows", as installed by the Python installer you get from python.org? This difference is significant; I would not expect Tkinter apps to work well using Pythonwin, because it has its own Win32 event loop. I don't understand why you'd need a root.destroy() after root.mainloop() exits -- when Python exits, it destroys the Tk windows anyway in my experience. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:06 Message: Logged In: YES user_id=33229 See my comments in bug 231207: IMHO all Tkinter programs need a root.destroy() after root.mainloop() Your test case DOES NOT die whether or not you deiconify it, if you run it under PythonWin. Your test case DOES die whether or not you deiconify it, whether or not you run it under PythonWin, if you add a root.destroy() after the root.mainloop() If you run it as a console script without the root.destroy() then Python reaches the end of the script and exits, without having shut Tk down first. PythonWin of course is not exiting at the end, and in the status line says the script returns with code 0. I think this is a usage/documentation error and is IMHO unrelated to the very real bug 216289. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 14:31 Message: Logged In: YES user_id=66570 Since I was also looking at #216289: Data using pythonw.exe (Taskinfo2000): Handles while running (before quit) 4 : Process 4 PID:FFF6F92D, C:\PYTHON20\PYTHONW.EXE C : Event 1 10 : Event 1 1C : Mutex 17 OLESCMLOCKMUTEX 20 : Event 1 24 : Event 1 -------------------------------------------------------- Handles while running Python.exe (before quit) |Handle||Type| |Refs||Name| 4 : Process 7 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 2 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 ThID:FFF79069, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 38 : Event 1 3C : Event 2 40 : Thread 1 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 44 : Event 1 48 : Event 2 4C : Thread 1 ThID:FFF53539, PID:FFF50719, C:\PYTHON20\PYTHON.EXE ---------------------------------------------------------- Handles AFTER trying to quit |Handle||Type| |Refs||Name| 4 : Process 4 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 1 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 38 : Event 1 3C : Event 1 40 : Thread 2 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE It appears that there is a thread NOT terminating. I just don't know how to go about finding it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 22:39 Message: Logged In: YES user_id=6380 I agree that this is likely the same as #216289. AFAIK it's a Tcl bug and we don't know what to do about it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-20 18:51 Message: Logged In: NO Interestingly enough, if you add a print statement after the mainloop(), it gets printed, showing the event loop exits properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 From noreply@sourceforge.net Thu Nov 7 15:12:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 07:12:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jon Ribbens (jribbens) >Assigned to: Martin v. Löwis (loewis) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-07 15:12 Message: Logged In: YES user_id=76089 Groovy, works now (in that Python builds and works, although it doesn't have the posix.makedev/major/minor features, which do appear to be available on OpenBSD). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 07:43 Message: Logged In: YES user_id=21627 Ok, I have now changed configure to link the test program, in configure 1.353, configure.in 1.364. Can you please confirm that this solves the problem? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-06 23:32 Message: Logged In: YES user_id=76089 I am using OpenBSD 2.7, but I think the very latest OpenBSD is just the same. I have investigated a bit more and you are right that _XOPEN_SOURCE is defined during configure. I *think* the problem is that the configure test used to detect HAVE_DEVICE_MACROS is broken. It is just trying to compile, but not link, "makedev(major(0),minor(0))", and it is not an error to try and compile that line even if makedev, major and minor are not defined since the compiler assumes they are unknown functions returning int. It is only an error at link time, and the configure test does not try to link the test code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 22:13 Message: Logged In: YES user_id=21627 On what version of OpenBSD does that happen? Also, can you find out why _XOPEN_SOURCE is not defined when testing for makedev? configure ought to define it while running the tests, and does that on my system. To be certain, you can add a line cp confdefs.h foo.h immediately before the test for makedev is run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Thu Nov 7 15:28:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 07:28:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-634444 ] Python does not build on OpenBSD Message-ID: Bugs item #634444, was opened at 2002-11-06 15:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Jon Ribbens (jribbens) Assigned to: Martin v. Löwis (loewis) Summary: Python does not build on OpenBSD Initial Comment: The new makedev/major/minor feature in posixmodule.c breaks the build on OpenBSD. These macros come from /usr/include/sys/types.h, and are conditional on: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) When ./configure is testing to find makedev etc, neither of these macros is defined so it finds them in types.h. However when posixmodule.c is compiled, _XOPEN_SOURCE is defined, so makedev etc are not available and the link fails. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 16:28 Message: Logged In: YES user_id=21627 Thanks for the confirmation. As for Python not exposing makedev: I consider this a OpenBSD bug. The system should provide a mechanism to expose extensions, even if _XOPEN_SOURCE is defined. Various such mechanisms exist, and Python uses whatever is available: Both _GNU_SOURCE and _OSF_SOURCE activate makedev on some systems (Linux, Tru64), and Python defines them all. I consider this ugly, since those extensions are neither specific to GNU nor OSF, but it works. The best approach in this specific case is to provide a header . This header is not specified in Posix, so applications using it clearly request this as an extension over Posix. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-07 16:12 Message: Logged In: YES user_id=76089 Groovy, works now (in that Python builds and works, although it doesn't have the posix.makedev/major/minor features, which do appear to be available on OpenBSD). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 08:43 Message: Logged In: YES user_id=21627 Ok, I have now changed configure to link the test program, in configure 1.353, configure.in 1.364. Can you please confirm that this solves the problem? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-07 00:32 Message: Logged In: YES user_id=76089 I am using OpenBSD 2.7, but I think the very latest OpenBSD is just the same. I have investigated a bit more and you are right that _XOPEN_SOURCE is defined during configure. I *think* the problem is that the configure test used to detect HAVE_DEVICE_MACROS is broken. It is just trying to compile, but not link, "makedev(major(0),minor(0))", and it is not an error to try and compile that line even if makedev, major and minor are not defined since the compiler assumes they are unknown functions returning int. It is only an error at link time, and the configure test does not try to link the test code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-06 23:13 Message: Logged In: YES user_id=21627 On what version of OpenBSD does that happen? Also, can you find out why _XOPEN_SOURCE is not defined when testing for makedev? configure ought to define it while running the tests, and does that on my system. To be certain, you can add a line cp confdefs.h foo.h immediately before the test for makedev is run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634444&group_id=5470 From noreply@sourceforge.net Thu Nov 7 15:57:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 07:57:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Thu Nov 7 16:03:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 08:03:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-07 17:03 Message: Logged In: YES user_id=11105 I couldn't get it to crash with Neil's code, so I checked it in without the Windows #ifdef: posixmodule.c, rev 2.271. BTW: I always assume we don't need NEWS entries for bug fixes, is this correct? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-05 23:33 Message: Logged In: YES user_id=33168 Thomas, I belivee the code below will check if the other cases crash. # test posixmodule.popen(), # would need check around line 2835 # as first code in popen() import posix # you may need a command that works, # I'm guessing cmd.exe is ok posix.popen('cmd.exe', '.zip') # test socketmodule.sock_makefile(), # would need check around line 1572 # after PyArg_ParseTuple from socket import * s = socket(AF_INET, SOCK_STREAM) s.makefile('.zip') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 22:14 Message: Logged In: YES user_id=31435 If socketmodule isn't crashing, I'd leave it alone. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 22:12 Message: Logged In: YES user_id=11105 Great, will do this tomorrow. What about socketmodule.c, which Neal mentioned? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 22:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 21:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 23:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 21:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 21:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 10:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 23:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Thu Nov 7 16:08:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 08:08:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-07 11:08 Message: Logged In: YES user_id=31435 Thanks! You certainly need a NEWS item for this, and possibly even a doc change, since requiring that mode strings begin with certain letters is a new language requirement. However unlikely, *somebody* may have code out there that will break because of it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-07 11:03 Message: Logged In: YES user_id=11105 I couldn't get it to crash with Neil's code, so I checked it in without the Windows #ifdef: posixmodule.c, rev 2.271. BTW: I always assume we don't need NEWS entries for bug fixes, is this correct? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-05 17:33 Message: Logged In: YES user_id=33168 Thomas, I belivee the code below will check if the other cases crash. # test posixmodule.popen(), # would need check around line 2835 # as first code in popen() import posix # you may need a command that works, # I'm guessing cmd.exe is ok posix.popen('cmd.exe', '.zip') # test socketmodule.sock_makefile(), # would need check around line 1572 # after PyArg_ParseTuple from socket import * s = socket(AF_INET, SOCK_STREAM) s.makefile('.zip') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:14 Message: Logged In: YES user_id=31435 If socketmodule isn't crashing, I'd leave it alone. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 16:12 Message: Logged In: YES user_id=11105 Great, will do this tomorrow. What about socketmodule.c, which Neal mentioned? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 16:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 15:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 17:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 15:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 15:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 04:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Thu Nov 7 16:12:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 08:12:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-07 17:12 Message: Logged In: YES user_id=11105 Sigh, even more work. In this case, it cannot be called a bugfix anymore... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-07 17:08 Message: Logged In: YES user_id=31435 Thanks! You certainly need a NEWS item for this, and possibly even a doc change, since requiring that mode strings begin with certain letters is a new language requirement. However unlikely, *somebody* may have code out there that will break because of it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-07 17:03 Message: Logged In: YES user_id=11105 I couldn't get it to crash with Neil's code, so I checked it in without the Windows #ifdef: posixmodule.c, rev 2.271. BTW: I always assume we don't need NEWS entries for bug fixes, is this correct? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-05 23:33 Message: Logged In: YES user_id=33168 Thomas, I belivee the code below will check if the other cases crash. # test posixmodule.popen(), # would need check around line 2835 # as first code in popen() import posix # you may need a command that works, # I'm guessing cmd.exe is ok posix.popen('cmd.exe', '.zip') # test socketmodule.sock_makefile(), # would need check around line 1572 # after PyArg_ParseTuple from socket import * s = socket(AF_INET, SOCK_STREAM) s.makefile('.zip') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 22:14 Message: Logged In: YES user_id=31435 If socketmodule isn't crashing, I'd leave it alone. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 22:12 Message: Logged In: YES user_id=11105 Great, will do this tomorrow. What about socketmodule.c, which Neal mentioned? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-05 22:06 Message: Logged In: YES user_id=31435 Cool! One thing: drop the Windows #ifdef. I asked Guido, and he agrees that Python wants to enforce this requirement on all platforms. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-05 21:40 Message: Logged In: YES user_id=11105 Here's a patch for Modules/posixmodule.c, which fixes this particular issue, conforming to Tim's requirements. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 23:57 Message: Logged In: YES user_id=31435 We generally don't check for valid mode characters because C allows implementations to extend the standard set, there's no way to query the platform about which mode extensions it supports, and we don't want to block users from using platform-specific mode extensions. It would be OK by me if we insisted that the first character be in "rwa", but checking more than that is off limits. Note that Windows simply ignores all of the mode chars starting with the first one it doesn't recognize: >>> f = open('example.txt', 'what a crock this mode string is!') >>> f >>> That was the same as passing "w". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 21:58 Message: Logged In: YES user_id=33168 Sounds good to me. Care to work on a patch with tests? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-04 21:36 Message: Logged In: YES user_id=11105 IMO we should check for a valid mode. There is a large surprise if python crashes with an access violation when the innocent user does innocent things like this. But this is just *my* opinion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:53 Message: Logged In: YES user_id=33168 We don't check anywhere else for valid mode chars. We would have to fix Modules/posixmodule.c and Modules/socketmodule if we wanted to check. Thomas, do you think a checks should be added or close this as a 3rd party problem? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-18 10:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 23:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Thu Nov 7 16:52:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 08:52:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash Message-ID: Bugs item #529750, was opened at 2002-03-14 04:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Adam M. Fass (afass) >Assigned to: Guido van Rossum (gvanrossum) Summary: Circular reference makes Py_Init crash Initial Comment: Call Py_Initialize(), create two objects that reference each other, then call Py_Finalize() and then Py_Intialize() again. This crashes Python with the following error message: Fatal Python error: UNREF invalid object The documentation on Py_Finalize() mentions that circular references will cause memory leaks, but it does not mention this behavior. Platform info: * Windows XP * Visual C++ 6.0 * Python 2.2 ------------------------------ #include "Python.h" int main(int argc, char* argv[]) { char *code1 = "class TestClass:\n\ti = 3\nt1 = TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = t1"; Py_Initialize(); PyRun_SimpleString(code1); Py_Finalize(); Py_Initialize(); Py_Finalize(); } ------------------------------ The string "code1" contains this python code: class TestClass: i = 3 t1 = TestClass() t2 = TestClass() t1.t = t2 t2.t = t1 ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-11-07 16:52 Message: Logged In: YES user_id=35752 A simpler bit of code to trigger the bug: Py_Initialize(); PyRun_SimpleString("x = []; x.append(x)\n"); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_DEBUG must be defined. I'm pretty sure the problem is caused by _Py_ResetReferences. It invalidates the invariant that _Py_ForgetReference is checking. The invariant check fails because the list lives across Py_Finalize and is freed the next time the GC is called. The correct fix is unclear to me. Maybe Guido has an idea. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 03:21 Message: Logged In: YES user_id=33168 I just tested w/a debug build in 2.3 and it crashed on me. It's probably a problem in 2.2.2. Neil, could you try to look at this? I removed the second Py_Finalize() and it still crashed. (gdb) p *op $4 = {_ob_next = 0x4020a7b4, _ob_prev = 0x8124418, ob_refcnt = 0, ob_type = 0x8121140} Note: ob_refcnt == 0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-14 00:51 Message: Logged In: YES user_id=33168 I just tried the sample code on 2.3.0 and 2.2.1+ on Linux. This didn't crash or misbehave at all. Did you compile python or did you get a binary distribution? Could there be an incompatibility? Can you otherwise use python w/o problems? Could it be specific to your box or windows in general? Can you build python -with-pydebug? Can you test with the python versions in CVS 2.2.1+ or 2.3? ---------------------------------------------------------------------- Comment By: Adam M. Fass (afass) Date: 2002-09-10 18:32 Message: Logged In: YES user_id=485533 I just tried my code with 2.2.1 and got the same exact result. My platform is still the same: Windows XP and Visual C++ 6.0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 22:54 Message: Logged In: YES user_id=33168 Adam, do you still have this problem, with 2.2.1+? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 18:44 Message: Logged In: YES user_id=35752 I can't reproduce this on Linux with the latest CVS code. I tried with and without Py_DEBUG defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 From noreply@sourceforge.net Thu Nov 7 17:10:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 09:10:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-633480 ] IOError w/ large string to CMD shell Message-ID: Bugs item #633480, was opened at 2002-11-04 16:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 Category: Windows Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 4 Submitted By: Michael McCandless (mikemccand) Assigned to: Tim Peters (tim_one) Summary: IOError w/ large string to CMD shell Initial Comment: If I try to run this program with "python2.2.1 -u": # 61409 works!! print ' ' * 61410 (which tries to print a string of 61,410 space characters), I get this Traceback on Windows 2000 SP2: Traceback (most recent call last): File "write.py", line 4, in ? print ' ' * 61410 IOError: [Errno 12] Not enough space Without "-u", this runs fine, and if I change "print" to "import sys; sys.stdout.write" instead, it still fails. I think this is happening in Objects/fileobject.c -- the calls to fwrite apparently don't write all bytes in win32 when the number of bytes is large -- seems like it may be necessary to parcel the data up into smaller pieces or something? NOTE: it's possible that the exact length of the string that fails may be larger on other OS's... ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-07 12:10 Message: Logged In: YES user_id=31435 I'm attaching a short C program showing that the same thing happens in straight C. But there's a surprise: turns out it has nothing to do with buffered versus unbuffered. It's changing stdout to binary mode that does the damage. This is also specific to writing to my Win2K console window ("DOS box"); if cmdline redirection is used to redirect stdout to a file instead, it doesn't fail. So, as threatened, closing this as WontFix -- if there's "a bug" here at all, it's in Microsoft's code. They may well claim it's a design limitation, if it were possible to talk with a human being there . Assigning to me and marking 3rdParty; I expect to close it as WontFix unless evidence appears that not a Windows bug. BTW, you may have better luck installing the Python Win32 extensions and using the Win32 file API directly. Sometimes that works better than MS's std-C I/O implementation. ---------------------------------------------------------------------- Comment By: Michael McCandless (mikemccand) Date: 2002-11-05 08:29 Message: Logged In: YES user_id=323786 Thanks for looking into this Tim... True, we can workaround it -- either don't run UNBUFFERED, or break up the strings before printing (override sys.stdout w/ our own file object that tries to break things up before printing), or don't run under "CMD" or other platform-specific shells that have this issue. But it's rather unexpected and to a "Python newbie" would be "surprising"; though I suppose most would not run with "- u". Also, from the IOError that's raised I don't know how many bytes were actually successfully written (apparently 0 in this case). NOTE: I'm able to reproduce on Windows XP Professional (no SP), running "cmd.exe", Python 2.2.2. I've also tried changing the "screen buffer" sizes on the CMD and it does not seem to change things. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-04 16:34 Message: Logged In: YES user_id=31435 Couldn't reproduce under Win98SE and 2.2.2 even boosting the size to a million. It *may* have to do with console-size settings under cmd.exe. Reduced the priority. "So don't do that" comes to mind . Seriously, if the platform C fwrite chokes, it's not Python's job to fix it -- it's Microsoft's. The interpreter isn't dying here, it's raising a well-behaved exception, just passing on the error the platform fwrite() raised. To me it's the same as the system malloc complaining that you don't have enough memory to satisfy a request: you've exceeded a platform limitation. If this is important to you, you can presumably fix it yourself by chunking up your writes in a loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633480&group_id=5470 From noreply@sourceforge.net Thu Nov 7 17:58:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 09:58:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash Message-ID: Bugs item #529750, was opened at 2002-03-13 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Adam M. Fass (afass) >Assigned to: Neil Schemenauer (nascheme) Summary: Circular reference makes Py_Init crash Initial Comment: Call Py_Initialize(), create two objects that reference each other, then call Py_Finalize() and then Py_Intialize() again. This crashes Python with the following error message: Fatal Python error: UNREF invalid object The documentation on Py_Finalize() mentions that circular references will cause memory leaks, but it does not mention this behavior. Platform info: * Windows XP * Visual C++ 6.0 * Python 2.2 ------------------------------ #include "Python.h" int main(int argc, char* argv[]) { char *code1 = "class TestClass:\n\ti = 3\nt1 = TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = t1"; Py_Initialize(); PyRun_SimpleString(code1); Py_Finalize(); Py_Initialize(); Py_Finalize(); } ------------------------------ The string "code1" contains this python code: class TestClass: i = 3 t1 = TestClass() t2 = TestClass() t1.t = t2 t2.t = t1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 12:58 Message: Logged In: YES user_id=6380 How about we simply get rid of _Py_ResetReferences()? It's only a debugging thing, it only makes a difference when you call Py_Initialize() again, it's *wrong* in that case, so I see no need to keep it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-07 11:52 Message: Logged In: YES user_id=35752 A simpler bit of code to trigger the bug: Py_Initialize(); PyRun_SimpleString("x = []; x.append(x)\n"); Py_Finalize(); Py_Initialize(); Py_Finalize(); Py_DEBUG must be defined. I'm pretty sure the problem is caused by _Py_ResetReferences. It invalidates the invariant that _Py_ForgetReference is checking. The invariant check fails because the list lives across Py_Finalize and is freed the next time the GC is called. The correct fix is unclear to me. Maybe Guido has an idea. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 22:21 Message: Logged In: YES user_id=33168 I just tested w/a debug build in 2.3 and it crashed on me. It's probably a problem in 2.2.2. Neil, could you try to look at this? I removed the second Py_Finalize() and it still crashed. (gdb) p *op $4 = {_ob_next = 0x4020a7b4, _ob_prev = 0x8124418, ob_refcnt = 0, ob_type = 0x8121140} Note: ob_refcnt == 0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 20:51 Message: Logged In: YES user_id=33168 I just tried the sample code on 2.3.0 and 2.2.1+ on Linux. This didn't crash or misbehave at all. Did you compile python or did you get a binary distribution? Could there be an incompatibility? Can you otherwise use python w/o problems? Could it be specific to your box or windows in general? Can you build python -with-pydebug? Can you test with the python versions in CVS 2.2.1+ or 2.3? ---------------------------------------------------------------------- Comment By: Adam M. Fass (afass) Date: 2002-09-10 14:32 Message: Logged In: YES user_id=485533 I just tried my code with 2.2.1 and got the same exact result. My platform is still the same: Windows XP and Visual C++ 6.0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:54 Message: Logged In: YES user_id=33168 Adam, do you still have this problem, with 2.2.1+? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 13:44 Message: Logged In: YES user_id=35752 I can't reproduce this on Linux with the latest CVS code. I tried with and without Py_DEBUG defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470 From noreply@sourceforge.net Thu Nov 7 18:48:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 10:48:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 19:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 19:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 17:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 17:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 15:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Thu Nov 7 19:02:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 11:02:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-635115 ] int(1e200) should return long Message-ID: Bugs item #635115, was opened at 2002-11-07 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635115&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: int(1e200) should return long Initial Comment: To remove the distinction between int and long int(1e200) should return a long object instead of raising an OverflowError. This is related to bug #629989: int("123123123123123123") doesn't work. Fixing this could be done by changing Objects/floatobject.c/float_int (see attached patch), but this changes the meaning of the nb_int slot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635115&group_id=5470 From noreply@sourceforge.net Thu Nov 7 19:05:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 11:05:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-634069 ] Errors in ** docs Message-ID: Bugs item #634069, was opened at 2002-11-05 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Guido van Rossum (gvanrossum) Summary: Errors in ** docs Initial Comment: Section 5.4 "The power operator" is out of date: 1. Raising a postive int to a negative int power no longer raises TypeError (it returns a float). 2. It's unclear what "a broken power" means. Raising a negative float to a non-integer power raises ValueError (not TypeError), if that's what it means. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-07 14:05 Message: Logged In: YES user_id=31435 Thanks, Raymond. I believe it accurately describes the CPython implementation today, but assigning to Guido so he can ponder whether this is how the language is defined (e.g., perhaps he wants to leave the door open for 2**-2 to return 1r/4 someday -- or perhaps not). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 01:58 Message: Logged In: YES user_id=80475 Tim, how does this patch look to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 From noreply@sourceforge.net Thu Nov 7 19:14:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 11:14:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-634069 ] Errors in ** docs Message-ID: Bugs item #634069, was opened at 2002-11-05 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Raymond Hettinger (rhettinger) Summary: Errors in ** docs Initial Comment: Section 5.4 "The power operator" is out of date: 1. Raising a postive int to a negative int power no longer raises TypeError (it returns a float). 2. It's unclear what "a broken power" means. Raising a negative float to a non-integer power raises ValueError (not TypeError), if that's what it means. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 14:14 Message: Logged In: YES user_id=6380 How do the docs for true division currently describe the results? If they say that with true division, int/int (and long/long and int/long etc.) returns a float, it's okay for the ** operator to say the same. In any case, I doubt that either of these will ever return a rational unless at least one of the arguments is a rational. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-07 14:05 Message: Logged In: YES user_id=31435 Thanks, Raymond. I believe it accurately describes the CPython implementation today, but assigning to Guido so he can ponder whether this is how the language is defined (e.g., perhaps he wants to leave the door open for 2**-2 to return 1r/4 someday -- or perhaps not). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 01:58 Message: Logged In: YES user_id=80475 Tim, how does this patch look to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 From noreply@sourceforge.net Thu Nov 7 19:49:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 11:49:52 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 20:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Thu Nov 7 20:00:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 12:00:16 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 20:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- >Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 21:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Thu Nov 7 21:34:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 13:34:17 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- >Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 16:34 Message: Logged In: YES user_id=116747 Another update: when there were more than [context] lines in between two updates, but less than 2 * [context], the two chunks should not be split. This version fixes that problem; we look ahead an extra [context] lines before cutting the chunk. Also, timestamps in headers are now show the seconds fraction as well, just like GNU diff. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 15:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Thu Nov 7 22:07:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 14:07:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 13:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 13:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 11:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Thu Nov 7 22:26:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 14:26:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 23:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 23:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 19:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 19:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 17:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 17:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 15:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Thu Nov 7 22:37:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 14:37:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:37 Message: Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 17:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 13:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 13:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 11:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Thu Nov 7 23:03:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 15:03:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-08 00:03 Message: Logged In: YES user_id=89016 The attached patch diffselect.txt should fix the select module. I'm not so sure, whether the check should be PyInt_Check or PyInt_CheckExact. What should be used instead of the PyNumber_Check() call? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 23:37 Message: Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 23:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 23:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 19:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 19:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 17:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 17:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 15:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Thu Nov 7 23:07:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 15:07:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 22:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Thu Nov 7 23:30:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 15:30:52 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-489899 ] bzip2 Message-ID: Feature Requests item #489899, was opened at 2001-12-06 17:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489899&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gábor BORGULYA (borgulya) Assigned to: Nobody/Anonymous (nobody) Summary: bzip2 Initial Comment: Hi ! I find the gzip module very useful, but I would use the bzip2 compression method instead, because it gives even more efficient compression. (For me ususally about extra 15%.) So, I would welcome a bzip2 module! http://sources.redhat.com/bzip2/index.html Yours, Gabor ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-08 00:30 Message: Logged In: YES user_id=89016 A module named bz2 is now in CVS. Can you try this out? If it does what you want, I think we can close the feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489899&group_id=5470 From noreply@sourceforge.net Fri Nov 8 01:06:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 17:06:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 01:07:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 17:07:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Raymond Hettinger (rhettinger) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 01:09:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 17:09:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:09 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 18:03 Message: Logged In: YES user_id=89016 The attached patch diffselect.txt should fix the select module. I'm not so sure, whether the check should be PyInt_Check or PyInt_CheckExact. What should be used instead of the PyNumber_Check() call? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:37 Message: Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 17:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 13:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 13:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 11:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Fri Nov 8 01:33:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 17:33:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:33 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:09 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 18:03 Message: Logged In: YES user_id=89016 The attached patch diffselect.txt should fix the select module. I'm not so sure, whether the check should be PyInt_Check or PyInt_CheckExact. What should be used instead of the PyNumber_Check() call? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:37 Message: Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 17:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 13:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 13:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 11:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Fri Nov 8 03:27:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 19:27:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-534669 ] remember to sync trees Message-ID: Bugs item #534669, was opened at 2002-03-25 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 2 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: remember to sync trees Initial Comment: There are various fixes hitting the trunk that I'm not considering for 2.2.1 that should probably be considered for 2.2.2 if that ever happens. Conversely there may be a few things I've fixed in the 22-maint branch that haven't been fixed on the trunk. Don't forget these. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-07 22:27 Message: Logged In: YES user_id=33168 Michael, I'm closing this on the assumption you don't need it any more or it's been overcome by events. Sorry if this is incorrect. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:45 Message: Logged In: YES user_id=33168 Michael, do you still want this kept open? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-05 04:58 Message: Logged In: YES user_id=6656 By looking at CVS logs? I don't think there were very many in fact (making StringIO work in --disable-unicode builds is the only one I can actually remember). I wasn't actually expecting *you* to do it at all -- I was going to do a log scan after 2.2.1 was done with (there's a reason I assigned this to myself). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-04 12:01 Message: Logged In: YES user_id=6380 How do I know what you fixed on the branch that should be moved to the trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470 From noreply@sourceforge.net Fri Nov 8 04:52:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 20:52:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-635327 ] IDLE GUI doesn't start Message-ID: Bugs item #635327, was opened at 2002-11-07 20:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635327&group_id=5470 Category: IDLE Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Rachelle Moore (moorere) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE GUI doesn't start Initial Comment: I downloaded the Python-2_2_2.exe self-extracting file from python.org, and successfully installed it on Win98. Both the IDLE GUI and command line interpreter seemed to work exactly as expected. I eventually found myself using the path browser to look at many modules, and it crashed. Being windows, this isn't an extraordinary event, so I simply went on to something else. I don't remember if I stopped IDLE and tried to come back to it, though I tend to think I did, and that it did work. That was yesterday. Today, after a cold restart, the IDLE GUI doesn't come up at all, though the command interpreter does. I notice that the \Python22\Tools\idle\README.txt says in part: "IDLE requires Python 1.5.2, so it is currently only usable with a Python 1.5.2 distribution." Hmm. Thank you. Rachelle Moore ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635327&group_id=5470 From noreply@sourceforge.net Fri Nov 8 05:05:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 21:05:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Raymond Hettinger (rhettinger) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 22:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 05:27:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 21:27:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Raymond Hettinger (rhettinger) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 05:30:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 21:30:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-634069 ] Errors in ** docs Message-ID: Bugs item #634069, was opened at 2002-11-05 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: Errors in ** docs Initial Comment: Section 5.4 "The power operator" is out of date: 1. Raising a postive int to a negative int power no longer raises TypeError (it returns a float). 2. It's unclear what "a broken power" means. Raising a negative float to a non-integer power raises ValueError (not TypeError), if that's what it means. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:30 Message: Logged In: YES user_id=80475 Amazingly, the docs do not describe the return values for true division; instead, they focus on floordiv(), as if it were the unusal case. Committing as ref5.tex 1.67. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 14:14 Message: Logged In: YES user_id=6380 How do the docs for true division currently describe the results? If they say that with true division, int/int (and long/long and int/long etc.) returns a float, it's okay for the ** operator to say the same. In any case, I doubt that either of these will ever return a rational unless at least one of the arguments is a rational. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-07 14:05 Message: Logged In: YES user_id=31435 Thanks, Raymond. I believe it accurately describes the CPython implementation today, but assigning to Guido so he can ponder whether this is how the language is defined (e.g., perhaps he wants to leave the door open for 2**-2 to return 1r/4 someday -- or perhaps not). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 01:58 Message: Logged In: YES user_id=80475 Tim, how does this patch look to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634069&group_id=5470 From noreply@sourceforge.net Fri Nov 8 05:35:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 21:35:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-635327 ] IDLE GUI doesn't start Message-ID: Bugs item #635327, was opened at 2002-11-07 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635327&group_id=5470 Category: IDLE Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Rachelle Moore (moorere) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE GUI doesn't start Initial Comment: I downloaded the Python-2_2_2.exe self-extracting file from python.org, and successfully installed it on Win98. Both the IDLE GUI and command line interpreter seemed to work exactly as expected. I eventually found myself using the path browser to look at many modules, and it crashed. Being windows, this isn't an extraordinary event, so I simply went on to something else. I don't remember if I stopped IDLE and tried to come back to it, though I tend to think I did, and that it did work. That was yesterday. Today, after a cold restart, the IDLE GUI doesn't come up at all, though the command interpreter does. I notice that the \Python22\Tools\idle\README.txt says in part: "IDLE requires Python 1.5.2, so it is currently only usable with a Python 1.5.2 distribution." Hmm. Thank you. Rachelle Moore ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:35 Message: Logged In: YES user_id=80475 I also had an IDLE experience upon updating to 2.2.2. The root cause turned out to be things left over in the install directory from prior python versions. I recommend clearing the whole directory tree and re-installing. If your problem goes away, please close this bug. The readme.txt file should really say, "Requires *at least* python 1.5.2 *or later*". I'll fixed the wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635327&group_id=5470 From noreply@sourceforge.net Fri Nov 8 06:12:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 22:12:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Raymond Hettinger (rhettinger) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 22:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 06:39:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 22:39:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Tim Peters (tim_one) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 22:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 07:52:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Nov 2002 23:52:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Raymond Hettinger (rhettinger) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-08 02:52 Message: Logged In: YES user_id=31435 Ah, of course -- that's what Jeremy saw the first time around! Sorry about that. Set element=it before the loop. Then UnboundLocalError is impossible, and it's also impossible for the iterator to leave element at that value (unless it never produces a value): except TypeError: try: data[element] = value except TypeError: the code we've got now else: # TypeError raised by iterator if element is it: # iterator didn't produce any values; # get rid of the bogus entry we just added del element[it] raise ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 09:32:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 01:32:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-635398 ] re.sub() coerces u'' to '' Message-ID: Bugs item #635398, was opened at 2002-11-08 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fredrik Lundh (effbot) Summary: re.sub() coerces u'' to '' Initial Comment: Using Python 2.2.1 on FreeBSD, these work as expected: >>> re.sub(u'f', u'b', u'foo') # keep string as Unicode u'boo' >>> re.sub(u'f', u'b', 'foo') # coerce string to Unicode u'boo' But this doesn't work the way I think it should: >>> re.sub(u'f', u'b', u'') # coerce string to non- Unicode?! > '' That is, an empty Unicode string does not survive as Unicode after going through re.sub(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 From noreply@sourceforge.net Fri Nov 8 10:33:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 02:33:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-534669 ] remember to sync trees Message-ID: Bugs item #534669, was opened at 2002-03-25 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470 Category: None Group: None Status: Closed Resolution: Out of Date Priority: 2 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: remember to sync trees Initial Comment: There are various fixes hitting the trunk that I'm not considering for 2.2.1 that should probably be considered for 2.2.2 if that ever happens. Conversely there may be a few things I've fixed in the 22-maint branch that haven't been fixed on the trunk. Don't forget these. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-08 10:33 Message: Logged In: YES user_id=6656 Uh, yeah, thanks. I need to catch up on my stuff here... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-08 03:27 Message: Logged In: YES user_id=33168 Michael, I'm closing this on the assumption you don't need it any more or it's been overcome by events. Sorry if this is incorrect. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 23:45 Message: Logged In: YES user_id=33168 Michael, do you still want this kept open? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-05 10:58 Message: Logged In: YES user_id=6656 By looking at CVS logs? I don't think there were very many in fact (making StringIO work in --disable-unicode builds is the only one I can actually remember). I wasn't actually expecting *you* to do it at all -- I was going to do a log scan after 2.2.1 was done with (there's a reason I assigned this to myself). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-04 18:01 Message: Logged In: YES user_id=6380 How do I know what you fixed on the branch that should be moved to the trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470 From noreply@sourceforge.net Fri Nov 8 11:39:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 03:39:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-635453 ] urllib.urlretrieve() with ftp error Message-ID: Bugs item #635453, was opened at 2002-11-08 12:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve() with ftp error Initial Comment: When using urllib.urlretrieve() to obtain a file through ftp and the file is not readable the directory listing of the file is returned. The expected behavior is that a "permission denied" error is generated. The current behavior makes it impossible to detect downloading a file failed. To reproduce: from urllib import urlretrieve fname = "/pub/vim/unstable/testfile" url = "ftp://ftp.vim.org" resfile, h = urlretrieve(url + fname) print "file contents: '%s'" % open(resfile).read() print "header stuff: ", h The result: file contents: '-rw------- 1 506 450 25 Nov 8 11:50 testfile ' Using ftplib.FTP() does result in the expected error: from ftplib import FTP def list(s): print s f = FTP("ftp.vim.org") f.login() f.retrbinary("RETR " + fname, list) f.quit() The last line of the resulting exception: ftplib.error_perm: 550 /pub/vim/unstable/testfile: Permission denied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470 From noreply@sourceforge.net Fri Nov 8 11:46:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 03:46:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords Message-ID: Bugs item #557704, was opened at 2002-05-18 19:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: netrc module can't handle all passwords Initial Comment: When a ~/.netrc file has a password with non-word characters parsing fails. Since it is recommended to use punctuation characters in passwords, this means most netrc files can't be parsed. An example of a line in ~/.netrc that fails: machine piet.puk.com login foo password bar! Additionally, entries in netrc may not have a login name (e.g., for mail servers). These entries should be silently skipped. An example of a line that fails: machine mail password fruit The included diff is a partial solution. It allows all ASCII punctuation characters to be used in passwords. Non-ASCII characters should probably also be allowed. ---------------------------------------------------------------------- >Comment By: Bram Moolenaar (vimboss) Date: 2002-11-08 12:46 Message: Logged In: YES user_id=57665 Note that the old Netrc class in the ftplib module has a different approach at parsing the .netrc file. This might actually work much better. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 20:43 Message: Logged In: YES user_id=6380 I think Fred knows this code. I think Eric Raymond (the original author) wrote this as an example of his shlex. :-) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-02 14:48 Message: Logged In: YES user_id=44345 I think a better solution would be to not use shlex to parse netrc files. Netrc files aren't shells. The whitespace is significant if it occurs inside a password. I'd just use re.split(r'(\s+)') and restore the password when I encounterd the "password" keyword. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-19 03:56 Message: Logged In: YES user_id=80475 Expanding keyspace is generally a good idea; however, the significance of meta-characters is bound to bite someone in the behind with a hard to find error. So, please reconsider single-quote, double-quote, backslash, greaterthan, lessthan, and pipe. Looking at first part of the patch, consider: - removing the TODO on line 31 - wrapping the character list in triple-quotes on line 32 - using the r'' form on line 32 to eliminate backslashes in the character list Looking at the second part of the patch, I don't follow (am perhaps being daft) why expanding the keyspace necessitates changing the login logic. The idea of allowing non-ASCII characters would be cool if the world had already universally accepted Latin-1 coding. That conflict is the reason that site.py defaults to ASCII encoding instead of handling non-US codings out of the box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470 From noreply@sourceforge.net Fri Nov 8 12:27:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 04:27:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Raymond Hettinger (rhettinger) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 07:27 Message: Logged In: YES user_id=6380 Counterexample: class C: def __init__(self, n=10): self.n = 10 def __iter__(self): return self def next(self): self.n -= 1 if self.n < 0: raise StopIteration return self def __hash__(self): raise TypeError ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 02:52 Message: Logged In: YES user_id=31435 Ah, of course -- that's what Jeremy saw the first time around! Sorry about that. Set element=it before the loop. Then UnboundLocalError is impossible, and it's also impossible for the iterator to leave element at that value (unless it never produces a value): except TypeError: try: data[element] = value except TypeError: the code we've got now else: # TypeError raised by iterator if element is it: # iterator didn't produce any values; # get rid of the bogus entry we just added del element[it] raise ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 13:10:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 05:10:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-614060 ] fpectl module broken on Linux Message-ID: Bugs item #614060, was opened at 2002-09-24 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614060&group_id=5470 Category: Extension Modules Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mats Wichmann (mwichmann) Assigned to: Nobody/Anonymous (nobody) Summary: fpectl module broken on Linux Initial Comment: Initial (minor) issue was that fpectl.c issues an unused variable warning compiling on Linux Itanium (ia64). On Itanium the _FPU_SETCW(cw) macro is a stub which does not reference cw. Turns out fpectl.c issues an explicit write of 0x1372 to the fpu control register via this macro, if found in the headers. With some further digging, here's the story as it seems on Linux: (1) fpectl.tex is out of date with respect to current behavior. Here's an excerpt (markup removed): +++++++ some floating point operations produce results that cannot be expressed as a normal floating point value. For example, try >>> import math >>> math.exp(1000) inf >>> math.exp(1000) / math.exp(1000) nan +++++++ However, current Python behaves like this: >>> math.exp(1000) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error (2) the fpectl module has no effect on ia64, where it's simply a stub. Behavior on other platforms such as Sparc, powerpc, etc might be unpredictable. (3) on i386, use of fpectl will cause Python to crash: Python 2.2.1 (#1, Jul 29 2002, 15:14:33) [GCC 3.2 (Mandrake Linux 9.0 3.2-0.1mdk)] on linux-i386 Type "help", "copyright", "credits" or "license" for more information. >>> import fpectl >>> import math >>> fpectl.turnon_sigfpe() >>> math.exp(1000) Fatal Python error: Unprotected floating point exception Aborted $ (4) Linux/glibc documentation suggests that the preferred interface for manipulating IEEE floating point exception and rouding behavior is with C99 standard routines fesetround() and fesetenv(). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-08 08:10 Message: Logged In: YES user_id=11375 The fpectl module has been removed from the setup.py in CVS and in Python 2.2.2, so it will no longer be compiled automatically. Thanks for pointing this out. Marking this bug as closed; figuring out a new interface for FPE control will probably need a PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614060&group_id=5470 From noreply@sourceforge.net Fri Nov 8 14:20:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 06:20:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700 Message-ID: Bugs item #425007, was opened at 2001-05-18 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: Python 2.1 installs shared libs with mode 0700 Initial Comment: I have gone back and tried Python 1.6 and 2.0. Both work fine. When I install Python 2.1, everything is broken. The problem is that when a module is a shared library (.so), python refuses to load the module. Example: import os import sys import SocketServer Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/SocketServer.py", line 126, in ? import socket File "/usr/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Now, do a "locate _socket.so" and I get: /usr/lib/python2.1/site-packages/_socket.so /usr/lib/python2.1/lib-dynload/_socket.so Clearly they are there, it's just that Python refuses to load them. I made Python 2.1 from source as fetched from the 2.1 tar ball. It makes cleanly. During the installation, I see some items that I believe to be minor that popup, but don't currectly expect that they are the problem. I have tried many times using different configure options to get this to work, deleting the previous installation each time. I've even tried installing in different locations. As is, Python 2.1 is completely broken for me. Surely I'm not the only one having this problem, especially since 1.5, 1.6, and 2.0 all work correctly. Any help would be great. BTW, doing a "print sys.path" gives me: ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/lib/python2.1/site-packages'] As you can see, lib-dynload is in the path, so I'm not really sure what's going on. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-08 14:20 Message: Logged In: YES user_id=6656 patch #629278 promises to help with this. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 00:47 Message: Logged In: NO Found a similar problem on Mac OS X's command line installation of Python 2.2.1. Darwin kernel 5.4 OS X 10.1.4. Apple's gcc 2.95.2. Built as regular user, umask 077. Ran make install as root, umask 022. All files in /usr/local/lib/python-2.2/lib-dynload were mode 711, which is not sufficient for python to load them. Same error as this problem "ImportError: No module named time". Error is clearer when viewed as: >>> help() help> modules time [Traceback redacted for brevity] IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.2/lib-dynload/MacOS.so' Suggest you add a comment on this to the README's Troubleshooting section. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 14:28 Message: Logged In: YES user_id=6656 I'll do something about this at some point. Using copy_tree to install shared libraries is gross. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-22 07:24 Message: Logged In: YES user_id=149084 INSTALLATION: Confirm. Built with umask 077, group and others have no permissions in source tree. (Note that if I su to install, the 077 follows! ok, install with umask of 022, normal for root.). Everything in installation looks ok except for lib-dynload, which has 700 permissions on files. No _socket.so in site-packages. REINSTALLATION: I suspect there is more to this than distutils...Redo the build with umask 022. Then chmod the whole previously installed tree to 700 and if you then repeat the install on top of it you find that while the .py files have been correctly copied by /usr/bin/install with 644, the .pyc and .pyo are still 700 though recompiled. This also happens in 1.5.2. The lib-dynload files are 755. This is with a umask of 022 for both the build user and root. Finally, delete a few files from lib-dynload, chmod the rest to 700, and make install again! The deleted files are restored at 755, the rest stay at 700. In general, messed up permissions are not fixed by a re-install. It would seem desirable that re-installing should result in exactly the same install tree as the initial install, including permissions, except that any non-distribution files (e.g. "site-packages") added by the user would be unaffected. If the user had modified some distribution .py files they would be reverted by the re-install, which does seem to be the case. A broken installation could be repaired by re-installing. Would that be a reasonable policy? Or is it too difficult to fix up all the permissions? A compromise might be to delete the .pyo .pyc before compiling, and explicitly chmod all the lib-dynload files during install. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 21:15 Message: Logged In: YES user_id=11375 Reclassifying as a Distutils bug. The install_lib subcommand simply copies the contents of the BUILD/ tree. It needs to pointedly ignore the umask and set the proper permissions on the installed files. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 20:32 Message: Logged In: YES user_id=6380 Assigning this to Andrew -- clearly the setup.py script (or distutils) needs to be fixed to fix this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 20:24 Message: Logged In: YES user_id=6380 I didn't mean to imply that you did something incorrectly. I just meant that there was some interaction between your system and Python that didn't work out the way it was supposed to be. Since Python installs correctly on most systems, I was implying that there's something unusual in your system that the Python install procedure doesn't anticipate. The mode 0700 for the shared libraries is a big hint at what was wrong (and if you had done an ls -l of the file when first reporting this we would have figured out the problem much quicker). Is perhaps the umask of the user who built (not installed) the files set to 077? In that case, the cause is that the "make install" by root doesn't change the file modes to something more reasonable (I've confirmed that this indeed happens). I'll look into whether this can be fixed. I'm changing the subject line of this bug report to reflect more accurately that the problem is with the file modes of shared libs. I still believe that the _socket.so in site-packages could not have been placed there by the normal Python install procedure. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2001-05-21 16:13 Message: Logged In: YES user_id=40173 The problem is that the installation is partially broken. It didn't install the shared libraries with proper permissions. When Python installed the shared libs, it installed the libs as root.root having 0700 permissions. When I tried to execute it as a normal user, obviously, it fails to load the shared lib. Python then, incorrectly reports that the shared lib can not be found. Of course, the correct solution is for Python to accurately report the problem and to have the installation always install the libraries with correct ownership and permission. I don't think I'm asking for too much here. Seems pretty reasonable to me. Anyone stating that I did not install correctly is woefully incorrect. Simply put, the installation is not 100%. As for some of the libraries existing twice. Well, simply put, the installation is not 100%. At any rate, I think it's safe to close this bug but we might want to add it to the faq-o-matic somewhere or some such thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-20 18:35 Message: Logged In: YES user_id=6380 Clearly it's something you have done to yourself. :-) The question is how to find out what. Try "python -v" or even "python -vv" and see what it prints when you try to import _socket. This should give you some clues (it shows where it searches for modules during import). As kbk says, that other _socket.so is mysterious. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-20 01:16 Message: Logged In: YES user_id=149084 Well, import SocketServer works ok for me with Python built both from the 2.1 tar file and the 2.2a0 CVS tree. I'm running Linux 2.2.5 (RH 6.2) on Pentium. Did you make clean after changing the configure options? It is not normal to have _socket.so in .../site-packages; it should be only in .../lib-dynload. Default installation has only the README file in site-packages. Your sys.path looks normal, except that Python default installs at /usr/local/[bin/lib]. I tried a build targeted at /usr/[bin/lib] and it was ok. You could try make clobber, but it's almost as fast to start over. Try a vanilla installation: 1. delete your install tree @ /usr/local/lib/python2.1 (and/or /usr/lib) 2. delete your source tree from wherever you unpacked the tar file. 3. untar again, cd to source directory it created 4. without changing any files, and no configure options, run ./configure, then make, then make install If that doesn't help, what Linux are you running, on what box, and where did you get your 2.1 tar file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:03:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:03:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-08 11:03 Message: Logged In: YES user_id=31435 Guido, to what is this a counterexample? It's a little too cryptic. If you try sets.Set(C()), it raises TypeError under the code that's been checked in, and it would also raise TypeError under the suggestion (via "the code we've got now"). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 07:27 Message: Logged In: YES user_id=6380 Counterexample: class C: def __init__(self, n=10): self.n = 10 def __iter__(self): return self def next(self): self.n -= 1 if self.n < 0: raise StopIteration return self def __hash__(self): raise TypeError ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 02:52 Message: Logged In: YES user_id=31435 Ah, of course -- that's what Jeremy saw the first time around! Sorry about that. Set element=it before the loop. Then UnboundLocalError is impossible, and it's also impossible for the iterator to leave element at that value (unless it never produces a value): except TypeError: try: data[element] = value except TypeError: the code we've got now else: # TypeError raised by iterator if element is it: # iterator didn't produce any values; # get rid of the bogus entry we just added del element[it] raise ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:18:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:18:02 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- >Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 11:18 Message: Logged In: YES user_id=116747 And another little bug found: if set a is empty and set b is not, resulting in all added lines, an empty diff would be returned. Attached latest version fixes this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 16:34 Message: Logged In: YES user_id=116747 Another update: when there were more than [context] lines in between two updates, but less than 2 * [context], the two chunks should not be split. This version fixes that problem; we look ahead an extra [context] lines before cutting the chunk. Also, timestamps in headers are now show the seconds fraction as well, just like GNU diff. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 15:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:19:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:19:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-233259 ] Ugly traceback for DistutilsPlatformError Message-ID: Bugs item #233259, was opened at 2001-02-20 11:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Ward (gward) >Assigned to: A.M. Kuchling (akuchling) Summary: Ugly traceback for DistutilsPlatformError Initial Comment: >From Chad Lester: > I was setting up a new redhat machine, and had forgotten to install the > python-devel rpm. The distutils provide a fairly ugly stack trace / error > message. Luckily, it meant something to me... but it's not terribly user > friendly! > > ... > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 368, in get_config_vars > func() > File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line > 280, in _init_posix > raise DistutilsPlatformError, my_msg > distutils.errors.DistutilsPlatformError: invalid Python > installation: unable to open /usr/lib/python1.5/config/Makefile (No such > file or directory) > > ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-08 11:19 Message: Logged In: YES user_id=11375 I've checked in my proposed fix (the more liberal version that catches all DistutilsError exceptions) as revision 1.54 of distutils/core.py. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-04 08:54 Message: Logged In: YES user_id=11375 A simple fix is in the attached patch; it simply adds DistutilsPlatformError to the list of the exception classes caught by core.setup(). However, maybe that exception handler should catch DistutilsError, instead of listing a few particular subclasses of it. Some subclasses represent internal errors or a bad setup file, but as users can always get the full traceback by setting the DISTUTILS_DEBUG environment variable, there seems little need to ever show the full traceback by default. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-12-06 11:18 Message: Logged In: YES user_id=11375 Greg, I don't understand your last comment on this bug. Surely the traceback will still be ugly for people running Python 2.2 or whatever who don't have the python-devel RPM installed? I don't see how this is only a 1.5.2 or a "installing Distutils" question. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2001-02-20 11:24 Message: This only applies for people installing Distutils under Python 1.5.2, so it will only be fixed if there is another Distutils release to support 1.5.2 -- which is unlikely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=233259&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:24:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:24:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-635570 ] remove debug prints from macmain.c Message-ID: Bugs item #635570, was opened at 2002-11-08 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635570&group_id=5470 Category: Macintosh Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: remove debug prints from macmain.c Initial Comment: I posted to the MacPython mailing list: pythonw does the following when run with a source file as its argument: % pythonw TUI.py original argc=2 original argv[0] = "/Applications/Python.app/Contents/MacOS/python" original argv[1] = "TUI.py" modified argc=2 modified argv[0] = "/Applications/Python.app/Contents/MacOS/python" modified argv[1] = "TUI.py" Details: - Everything is built as per the instructions I posted at http://www.astro.washington.edu/owen in particular: - MacOS X 10.2 - Python 2.2.2 framework built from source, with setup.py modified to be similar to or identical to the 2.3a0 setup.py, so it can find aqua Tk 8.4.1 - The file pythonw is: #!/bin/sh exec /Applications/Python.app/Contents/MacOS/python $@ Jack Jansen kindly suggested that I could fix this by removing the debug prints from macmain.c and rebuilding. He also asked me to file this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635570&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:42:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:42:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 11:42 Message: Logged In: YES user_id=6380 The counterexample was trying to defeat your assertion "it's also impossible for the iterator to leave element at that value". It doesn't work, but I'm not at all convinced that that assertion can't be defeated. I find the code you suggest too convoluted to accept. Raymond's code is less convoluted, but still ugly (the list of exceptions is a little too long for comfort). It is can also be inefficient (e.g. if you have a subclass of list) and redundant (there's a check for dict earlier, so dict doesn't need to be tested). I'll check in my version, you can review it in CVS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 11:03 Message: Logged In: YES user_id=31435 Guido, to what is this a counterexample? It's a little too cryptic. If you try sets.Set(C()), it raises TypeError under the code that's been checked in, and it would also raise TypeError under the suggestion (via "the code we've got now"). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 07:27 Message: Logged In: YES user_id=6380 Counterexample: class C: def __init__(self, n=10): self.n = 10 def __iter__(self): return self def next(self): self.n -= 1 if self.n < 0: raise StopIteration return self def __hash__(self): raise TypeError ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 02:52 Message: Logged In: YES user_id=31435 Ah, of course -- that's what Jeremy saw the first time around! Sorry about that. Set element=it before the loop. Then UnboundLocalError is impossible, and it's also impossible for the iterator to leave element at that value (unless it never produces a value): except TypeError: try: data[element] = value except TypeError: the code we've got now else: # TypeError raised by iterator if element is it: # iterator didn't produce any values; # get rid of the bogus entry we just added del element[it] raise ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:58:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:58:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-08 11:58 Message: Logged In: YES user_id=31435 Maybe my suggestion wasn't clear. The snippet unique = [] x = unique for x in y: whatever can't possibly leave x is unique true if the for loop ever binds anything to x, and that's not deep. It could fail if iterating y managed to produce unique as a value, but then "unique" is misnamed . So, sure, an iterator "itself" that produced iter(itself) as one of its values could defeat the assertion. Nothing else could. Live a little . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 11:42 Message: Logged In: YES user_id=6380 The counterexample was trying to defeat your assertion "it's also impossible for the iterator to leave element at that value". It doesn't work, but I'm not at all convinced that that assertion can't be defeated. I find the code you suggest too convoluted to accept. Raymond's code is less convoluted, but still ugly (the list of exceptions is a little too long for comfort). It is can also be inefficient (e.g. if you have a subclass of list) and redundant (there's a check for dict earlier, so dict doesn't need to be tested). I'll check in my version, you can review it in CVS. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 11:03 Message: Logged In: YES user_id=31435 Guido, to what is this a counterexample? It's a little too cryptic. If you try sets.Set(C()), it raises TypeError under the code that's been checked in, and it would also raise TypeError under the suggestion (via "the code we've got now"). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 07:27 Message: Logged In: YES user_id=6380 Counterexample: class C: def __init__(self, n=10): self.n = 10 def __iter__(self): return self def next(self): self.n -= 1 if self.n < 0: raise StopIteration return self def __hash__(self): raise TypeError ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 02:52 Message: Logged In: YES user_id=31435 Ah, of course -- that's what Jeremy saw the first time around! Sorry about that. Set element=it before the loop. Then UnboundLocalError is impossible, and it's also impossible for the iterator to leave element at that value (unless it never produces a value): except TypeError: try: data[element] = value except TypeError: the code we've got now else: # TypeError raised by iterator if element is it: # iterator didn't produce any values; # get rid of the bogus entry we just added del element[it] raise ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 01:12 Message: Logged In: YES user_id=80475 The line, "for element in it:" may fail immediately, before "element" is ever assigned. The re-test of "date [element] = value" then raises an UnboundLocalError. Did you want to trap that exception too? The resulting code is somewhat ugly but is fast and clear about its intentions. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-08 00:27 Message: Logged In: YES user_id=31435 Reopened. The difficulty remaining appears to be that we're assuming TypeError was raised by the data[element] = value part, when it *may* have been raised by the for element in it: part. If so, this could be addressed directly instead of via materializing the whole iterable into a list first. Like: except TypeError: try: data[element] = value except TypeError: the code we've got now else: raise # must have come from iteration ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-08 00:05 Message: Logged In: YES user_id=80475 Done. See sets.py 1.32 and test/test_sets.py 1.14. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:06 Message: Logged In: YES user_id=6380 Yikes! You meant type(iterable), not type(iter). I expect this will get complaints from people who write careful iterators. But it seems the best compromise for now, so check it in (with above fix). I doubt this is the last word though. :-( It needs a unittest that tries this with each of the mentioned types as well as with something that's not one of them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 18:07 Message: Logged In: YES user_id=80475 Revised patch that avoids performance issues in cases where the iterator won't raise errors during iteration. For the other cases, list(iter) is still faster than inserting a try/except inside the loop. Please pronounce one way or the other and then re-assign to me. I'll move the try/except back inside the loop if that's what you want. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-02 19:02 Message: Logged In: YES user_id=6380 Hmm... It's the performance waste of always making an unnecessary copy (the argument will often already be a list, or a tuple) vs. the performance waste of doing try/except each iteration. Maybe it should all be replaced by this? for element in iterable: transform = getattr(element, "_as_immutable", None) if transform is not None: element = transform() data[element] = value ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 23:09 Message: Logged In: YES user_id=80475 Yes. The intended behavior is to have list(iterable) run the iterable start to finish so that any exceptions raised will not be trapped by the Sets code during dictionary construction. Feel free to disregard the idea. I thought it had some merit because it is simple, fast and fixes the problem. Still, it looks weird and I won't lose any sleep if you toss the idea. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-31 21:03 Message: Logged In: YES user_id=6380 That patch makes no sense -- it first materializes the iterator as a list, then iterates over that. Was that what you intended? I'd rather give up on the speediness and put the try/except where it belongs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-25 23:39 Message: Logged In: YES user_id=80475 A simple solution is to run through the iterator once before starting the update. A one line patch is attached. The only thing I don't like about it is that the code is starting to look hare-brained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Fri Nov 8 16:58:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 08:58:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-635327 ] IDLE GUI doesn't start Message-ID: Bugs item #635327, was opened at 2002-11-07 20:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635327&group_id=5470 Category: IDLE Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Rachelle Moore (moorere) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE GUI doesn't start Initial Comment: I downloaded the Python-2_2_2.exe self-extracting file from python.org, and successfully installed it on Win98. Both the IDLE GUI and command line interpreter seemed to work exactly as expected. I eventually found myself using the path browser to look at many modules, and it crashed. Being windows, this isn't an extraordinary event, so I simply went on to something else. I don't remember if I stopped IDLE and tried to come back to it, though I tend to think I did, and that it did work. That was yesterday. Today, after a cold restart, the IDLE GUI doesn't come up at all, though the command interpreter does. I notice that the \Python22\Tools\idle\README.txt says in part: "IDLE requires Python 1.5.2, so it is currently only usable with a Python 1.5.2 distribution." Hmm. Thank you. Rachelle Moore ---------------------------------------------------------------------- >Comment By: Rachelle Moore (moorere) Date: 2002-11-08 08:58 Message: Logged In: YES user_id=644612 Deleted with Win98 "add/remove programs," then deleted subdirectories themselves. Reinstalled from the same copy of its self-extracting file; it still works after two cold restarts. Yay! Provisionally I would relate the discrepency to some sort of overflow within the path browser. Before it first crashed IDLE, I had briefly opened 20-30 modules for examination, and at one point had 6-8 "Python Shell" windows open. (There was no previous installation of Python, unless dustbunnies can program.) Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-07 21:35 Message: Logged In: YES user_id=80475 I also had an IDLE experience upon updating to 2.2.2. The root cause turned out to be things left over in the install directory from prior python versions. I recommend clearing the whole directory tree and re-installing. If your problem goes away, please close this bug. The readme.txt file should really say, "Requires *at least* python 1.5.2 *or later*". I'll fixed the wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635327&group_id=5470 From noreply@sourceforge.net Fri Nov 8 17:29:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 09:29:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-635595 ] Misleading description of \w in regexs Message-ID: Bugs item #635595, was opened at 2002-11-08 08:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635595&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Misleading description of \w in regexs Initial Comment: In the Regular Expression Syntax doc page (http://www.python.org/dev/doc/devel/lib/re-syntax.html), the description for \w is misleading (the same goes for \W). The description indicates that, with the locale flag in effect, \w includes "characters defined as letters" for the current locale. In reading that, I took "letters" to mean characters for which isalpha returns true, but, in fact, all characters defined as alphanumerics for the current locale are included (so \w works pretty much the same way with locale flag as with the unicode flag). For example (using '\xb2', the superscript two): Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'English_United States.1252' >>> import re >>> re.match(r'\w', '\xb2', re.L).group() '\xb2' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635595&group_id=5470 From noreply@sourceforge.net Fri Nov 8 19:14:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 11:14:29 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- >Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 14:14 Message: Logged In: YES user_id=116747 'Nother version. One bug fix, one new feature. - When two hunks were between 2 * context + 1 and 3* context lines aparart, the starting context for the second hunk would be partially lost. - Handle missing newline on the last line like GNU diff does. This currently only supports UNIX-style lineendings. Documentation reflects this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 11:18 Message: Logged In: YES user_id=116747 And another little bug found: if set a is empty and set b is not, resulting in all added lines, an empty diff would be returned. Attached latest version fixes this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 16:34 Message: Logged In: YES user_id=116747 Another update: when there were more than [context] lines in between two updates, but less than 2 * [context], the two chunks should not be split. This version fixes that problem; we look ahead an extra [context] lines before cutting the chunk. Also, timestamps in headers are now show the seconds fraction as well, just like GNU diff. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 15:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Fri Nov 8 23:35:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 15:35:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-627864 ] curses library not found during make Message-ID: Bugs item #627864, was opened at 2002-10-23 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 Category: Installation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Javier Streb (jstreb) Assigned to: Nobody/Anonymous (nobody) Summary: curses library not found during make Initial Comment: Hi, I'm compiling Python v. 2.2.2 on an RS/6000 running AIX v 4.3.3.75 using gnu.gcc version 2.95.3.0 as the compiler. In the configuration phase I had to specify "./configure --with-gcc" because it was telling me the "C compiler cannot create executables". gcc is the only compiler on the machine. During the "make" after a quite a lot of processing I get: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/wwwlogs/python/Python-2.2.2/./Include -I/usr/local/include -I/wwwlogs/python/Python-2.2.2/Include -I/wwwlogs/python/Python-2.2.2 -c /wwwlogs/python/Python-2.2.2/Modules/_cursesmodule.c -o build/temp.aix-4.3-2.2/_cursesmodule.o ./Modules/ld_so_aix gcc -bI:Modules/python.exp build/temp.aix-4.3-2.2/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-4.3-2.2/_curses.so collect2: Library libtermcap not found WARNING: removing "_curses" since importing it failed error: build/lib.aix-4.3-2.2/_curses.so: No such file or directory make: 1254-004 The error code from the last command is 1. I have /usr/include/curses.h in the system and will attempt to recompile using that library. Any pointers will be much appreciated ---------------------------------------------------------------------- >Comment By: Javier Streb (jstreb) Date: 2002-11-08 15:35 Message: Logged In: YES user_id=634883 Found curses library and installed ncurses and readline. Had problems specifying libraries during link editing process. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 12:52 Message: Logged In: YES user_id=21627 On the "C compiler not found": Can you please attach the config.log of a run that aborts with that message (and/or read it yourself and draw conclusions). On curses: It does not find libtermcap. The header file alone is insufficient; you need the library as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 From noreply@sourceforge.net Fri Nov 8 23:35:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 15:35:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-627864 ] curses library not found during make Message-ID: Bugs item #627864, was opened at 2002-10-23 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 Category: Installation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Javier Streb (jstreb) Assigned to: Nobody/Anonymous (nobody) Summary: curses library not found during make Initial Comment: Hi, I'm compiling Python v. 2.2.2 on an RS/6000 running AIX v 4.3.3.75 using gnu.gcc version 2.95.3.0 as the compiler. In the configuration phase I had to specify "./configure --with-gcc" because it was telling me the "C compiler cannot create executables". gcc is the only compiler on the machine. During the "make" after a quite a lot of processing I get: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/wwwlogs/python/Python-2.2.2/./Include -I/usr/local/include -I/wwwlogs/python/Python-2.2.2/Include -I/wwwlogs/python/Python-2.2.2 -c /wwwlogs/python/Python-2.2.2/Modules/_cursesmodule.c -o build/temp.aix-4.3-2.2/_cursesmodule.o ./Modules/ld_so_aix gcc -bI:Modules/python.exp build/temp.aix-4.3-2.2/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-4.3-2.2/_curses.so collect2: Library libtermcap not found WARNING: removing "_curses" since importing it failed error: build/lib.aix-4.3-2.2/_curses.so: No such file or directory make: 1254-004 The error code from the last command is 1. I have /usr/include/curses.h in the system and will attempt to recompile using that library. Any pointers will be much appreciated ---------------------------------------------------------------------- >Comment By: Javier Streb (jstreb) Date: 2002-11-08 15:35 Message: Logged In: YES user_id=634883 Found curses library and installed ncurses and readline. Had problems specifying libraries during link editing process. ---------------------------------------------------------------------- Comment By: Javier Streb (jstreb) Date: 2002-11-08 15:35 Message: Logged In: YES user_id=634883 Found curses library and installed ncurses and readline. Had problems specifying libraries during link editing process. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 12:52 Message: Logged In: YES user_id=21627 On the "C compiler not found": Can you please attach the config.log of a run that aborts with that message (and/or read it yourself and draw conclusions). On curses: It does not find libtermcap. The header file alone is insufficient; you need the library as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 From noreply@sourceforge.net Sat Nov 9 02:30:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 18:30:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-635814 ] cStringIO().write TypeError Message-ID: Bugs item #635814, was opened at 2002-11-08 18:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: kris kvilekval (kgk) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO().write TypeError Initial Comment: There is an incompatibilty between StringIO and cStringIO, as demonstrated below.. Passing an integer to StringIO.write is OK while it not OK to pass one to cStringIO. $ python Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO >>> sfile = StringIO.StringIO() >>> sfile.write (100) >>> print sfile.getvalue() 100 >>> import cStringIO >>> cfile = cStringIO.StringIO() >>> cfile.write (100) Traceback (most recent call last): File "", line 1, in ? TypeError: write() argument 1 must be string or read-only buffer, not int >>> cfile.write (str(100)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 From noreply@sourceforge.net Sat Nov 9 07:33:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Nov 2002 23:33:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-627864 ] curses library not found during make Message-ID: Bugs item #627864, was opened at 2002-10-24 03:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 Category: Installation Group: Python 2.2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Javier Streb (jstreb) Assigned to: Nobody/Anonymous (nobody) Summary: curses library not found during make Initial Comment: Hi, I'm compiling Python v. 2.2.2 on an RS/6000 running AIX v 4.3.3.75 using gnu.gcc version 2.95.3.0 as the compiler. In the configuration phase I had to specify "./configure --with-gcc" because it was telling me the "C compiler cannot create executables". gcc is the only compiler on the machine. During the "make" after a quite a lot of processing I get: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/wwwlogs/python/Python-2.2.2/./Include -I/usr/local/include -I/wwwlogs/python/Python-2.2.2/Include -I/wwwlogs/python/Python-2.2.2 -c /wwwlogs/python/Python-2.2.2/Modules/_cursesmodule.c -o build/temp.aix-4.3-2.2/_cursesmodule.o ./Modules/ld_so_aix gcc -bI:Modules/python.exp build/temp.aix-4.3-2.2/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-4.3-2.2/_curses.so collect2: Library libtermcap not found WARNING: removing "_curses" since importing it failed error: build/lib.aix-4.3-2.2/_curses.so: No such file or directory make: 1254-004 The error code from the last command is 1. I have /usr/include/curses.h in the system and will attempt to recompile using that library. Any pointers will be much appreciated ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 08:33 Message: Logged In: YES user_id=21627 For specifying additional libraries in places where setup.py may not look, I recommend to edit Modules/Setup. This allows you the precise specification of library paths, on a per-module basis. You only need to configure the modules in Setup that Python fails to configure correctly on its own. It seems there are no issues left, so I close this report. ---------------------------------------------------------------------- Comment By: Javier Streb (jstreb) Date: 2002-11-09 00:35 Message: Logged In: YES user_id=634883 Found curses library and installed ncurses and readline. Had problems specifying libraries during link editing process. ---------------------------------------------------------------------- Comment By: Javier Streb (jstreb) Date: 2002-11-09 00:35 Message: Logged In: YES user_id=634883 Found curses library and installed ncurses and readline. Had problems specifying libraries during link editing process. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 21:52 Message: Logged In: YES user_id=21627 On the "C compiler not found": Can you please attach the config.log of a run that aborts with that message (and/or read it yourself and draw conclusions). On curses: It does not find libtermcap. The header file alone is insufficient; you need the library as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 From noreply@sourceforge.net Sat Nov 9 08:37:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 00:37:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-635862 ] Py 2.2.2 does not build on latest Cygwin Message-ID: Bugs item #635862, was opened at 2002-11-09 03:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: Py 2.2.2 does not build on latest Cygwin Initial Comment: Trying to compile Python 2.2.2 with latest Cygwin version under XP fails with the attached compilation errors....might be a Cygwin problem but I have no idea how to verify that. -aj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 From noreply@sourceforge.net Sat Nov 9 12:40:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 04:40:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-635862 ] Py 2.2.2 does not build on latest Cygwin Message-ID: Bugs item #635862, was opened at 2002-11-09 08:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Jason Tishler (jlt63) Summary: Py 2.2.2 does not build on latest Cygwin Initial Comment: Trying to compile Python 2.2.2 with latest Cygwin version under XP fails with the attached compilation errors....might be a Cygwin problem but I have no idea how to verify that. -aj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 From noreply@sourceforge.net Sat Nov 9 14:38:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 06:38:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-635862 ] Py 2.2.2 does not build on latest Cygwin Message-ID: Bugs item #635862, was opened at 2002-11-08 23:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Jason Tishler (jlt63) Summary: Py 2.2.2 does not build on latest Cygwin Initial Comment: Trying to compile Python 2.2.2 with latest Cygwin version under XP fails with the attached compilation errors....might be a Cygwin problem but I have no idea how to verify that. -aj ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-11-09 05:38 Message: Logged In: YES user_id=86216 This is a known Cygwin fork() issue. Please see the following for some background: http://www.cygwin.com/ml/cygwin/2001-12/msg00894.html http://sources.redhat.com/ml/cygwin/2002-07/msg00276.html Use the following to workaround this problem: $ # stop all Cygwin processes except for a single bash $ wget -nd -P /usr/local/bin http://www.tishler.net/jason/software/rebase/rebase.exe $ cd /usr/bin $ rebase -v -b 0x68000000 -d -o 0x10000 *.dll $ make Does the build succeed now? If not, then I have some other workarounds. Please let me know either way. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 From noreply@sourceforge.net Sat Nov 9 14:40:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 06:40:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-635929 ] 2.2.2 build on Solaris Message-ID: Bugs item #635929, was opened at 2002-11-09 09:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635929&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2.2 build on Solaris Initial Comment: Attached is a message that concludes an exchange between David LeVine and me. He built Python using the gcc 3.2 from sunfreeware.com. Running ./python, he got this error: ld.so.1: ./python: fatal: libstdc++.so.5: open failed: No such file or directory I suggested adding a -R somewhere and he got it to work by patching configure. Perhaps a real fix can be made out of this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635929&group_id=5470 From noreply@sourceforge.net Sat Nov 9 15:03:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 07:03:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-635862 ] Py 2.2.2 does not build on latest Cygwin Message-ID: Bugs item #635862, was opened at 2002-11-09 03:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 Category: Build Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Jason Tishler (jlt63) Summary: Py 2.2.2 does not build on latest Cygwin Initial Comment: Trying to compile Python 2.2.2 with latest Cygwin version under XP fails with the attached compilation errors....might be a Cygwin problem but I have no idea how to verify that. -aj ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2002-11-09 10:03 Message: Logged In: YES user_id=11084 the workaround worked for me. tnx, -aj ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-11-09 09:38 Message: Logged In: YES user_id=86216 This is a known Cygwin fork() issue. Please see the following for some background: http://www.cygwin.com/ml/cygwin/2001-12/msg00894.html http://sources.redhat.com/ml/cygwin/2002-07/msg00276.html Use the following to workaround this problem: $ # stop all Cygwin processes except for a single bash $ wget -nd -P /usr/local/bin http://www.tishler.net/jason/software/rebase/rebase.exe $ cd /usr/bin $ rebase -v -b 0x68000000 -d -o 0x10000 *.dll $ make Does the build succeed now? If not, then I have some other workarounds. Please let me know either way. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635862&group_id=5470 From noreply@sourceforge.net Sat Nov 9 17:53:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 09:53:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 18:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Sat Nov 9 18:02:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 10:02:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-635929 ] 2.2.2 build on Solaris Message-ID: Bugs item #635929, was opened at 2002-11-09 15:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635929&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2.2 build on Solaris Initial Comment: Attached is a message that concludes an exchange between David LeVine and me. He built Python using the gcc 3.2 from sunfreeware.com. Running ./python, he got this error: ld.so.1: ./python: fatal: libstdc++.so.5: open failed: No such file or directory I suggested adding a -R somewhere and he got it to work by patching configure. Perhaps a real fix can be made out of this? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:02 Message: Logged In: YES user_id=21627 I'm not sure that this should be fixed in Python, there are several complications: 1. It is not certain that python is linked with libstdc++. If not, you only need to worry about libgcc_s.so, if gcc is gcc 3.2. 2. It is not certain whether /usr/local is the right prefix; gcc might be installed with a different prefix. 3. It is not certain whether libstdc++ is installed in /lib, gcc also supports installing it into /lib/gcc-lib// 4. Randomly adding -R options might shoot back, since python may now pick up the wrong libraries, for libraries used in extension modules. We usually fix this in the gcc installation, not in all affected applications, by adding proper -R options into the installed specs file. I would rather "fix" this by pointing out that gcc 3 users will have to set LD_RUN_PATH on Solaris, to include the directories containing libgcc_s.so.1, and possibly libstdc++.so.xy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635929&group_id=5470 From noreply@sourceforge.net Sat Nov 9 18:04:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 10:04:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-635814 ] cStringIO().write TypeError Message-ID: Bugs item #635814, was opened at 2002-11-09 03:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: kris kvilekval (kgk) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO().write TypeError Initial Comment: There is an incompatibilty between StringIO and cStringIO, as demonstrated below.. Passing an integer to StringIO.write is OK while it not OK to pass one to cStringIO. $ python Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO >>> sfile = StringIO.StringIO() >>> sfile.write (100) >>> print sfile.getvalue() 100 >>> import cStringIO >>> cfile = cStringIO.StringIO() >>> cfile.write (100) Traceback (most recent call last): File "", line 1, in ? TypeError: write() argument 1 must be string or read-only buffer, not int >>> cfile.write (str(100)) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:04 Message: Logged In: YES user_id=21627 This is by design. The file protocol makes no guarantee that you can write objects other than strings into a file, unless the object explicitly documents the support for other objects. cStringIO differs in many ways from StringIO, this is but one way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 From noreply@sourceforge.net Sat Nov 9 18:05:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 10:05:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-635398 ] re.sub() coerces u'' to '' Message-ID: Bugs item #635398, was opened at 2002-11-08 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fredrik Lundh (effbot) Summary: re.sub() coerces u'' to '' Initial Comment: Using Python 2.2.1 on FreeBSD, these work as expected: >>> re.sub(u'f', u'b', u'foo') # keep string as Unicode u'boo' >>> re.sub(u'f', u'b', 'foo') # coerce string to Unicode u'boo' But this doesn't work the way I think it should: >>> re.sub(u'f', u'b', u'') # coerce string to non- Unicode?! > '' That is, an empty Unicode string does not survive as Unicode after going through re.sub(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:05 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 From noreply@sourceforge.net Sat Nov 9 18:48:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 10:48:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-635398 ] re.sub() coerces u'' to '' Message-ID: Bugs item #635398, was opened at 2002-11-08 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fredrik Lundh (effbot) Summary: re.sub() coerces u'' to '' Initial Comment: Using Python 2.2.1 on FreeBSD, these work as expected: >>> re.sub(u'f', u'b', u'foo') # keep string as Unicode u'boo' >>> re.sub(u'f', u'b', 'foo') # coerce string to Unicode u'boo' But this doesn't work the way I think it should: >>> re.sub(u'f', u'b', u'') # coerce string to non- Unicode?! > '' That is, an empty Unicode string does not survive as Unicode after going through re.sub(). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-11-09 19:48 Message: Logged In: YES user_id=38376 this buglet has already been fixed in the SRE master repository. here's the relevant portion: *** 1802,1808 **** switch (PyList_GET_SIZE(list)) { case 0: Py_DECREF(list); ! return PyString_FromString(""); case 1: result = PyList_GET_ITEM(list, 0); Py_INCREF(result); --- 1785,1791 ---- switch (PyList_GET_SIZE(list)) { case 0: Py_DECREF(list); ! return PySequence_GetSlice(pattern, 0, 0); case 1: result = PyList_GET_ITEM(list, 0); Py_INCREF(result); I'll update the Python repository asap (once I've gotten around to merge in some changes done in the Python repository). PS. also see my post on comp.lang.python on this topic. well-written unicode code shouldn't care about things like this... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:05 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 From noreply@sourceforge.net Sat Nov 9 18:50:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 10:50:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-635398 ] re.sub() coerces u'' to '' Message-ID: Bugs item #635398, was opened at 2002-11-08 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Open Resolution: Accepted >Priority: 3 Submitted By: Mike Brown (mike_j_brown) Assigned to: Fredrik Lundh (effbot) Summary: re.sub() coerces u'' to '' Initial Comment: Using Python 2.2.1 on FreeBSD, these work as expected: >>> re.sub(u'f', u'b', u'foo') # keep string as Unicode u'boo' >>> re.sub(u'f', u'b', 'foo') # coerce string to Unicode u'boo' But this doesn't work the way I think it should: >>> re.sub(u'f', u'b', u'') # coerce string to non- Unicode?! > '' That is, an empty Unicode string does not survive as Unicode after going through re.sub(). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-11-09 19:48 Message: Logged In: YES user_id=38376 this buglet has already been fixed in the SRE master repository. here's the relevant portion: *** 1802,1808 **** switch (PyList_GET_SIZE(list)) { case 0: Py_DECREF(list); ! return PyString_FromString(""); case 1: result = PyList_GET_ITEM(list, 0); Py_INCREF(result); --- 1785,1791 ---- switch (PyList_GET_SIZE(list)) { case 0: Py_DECREF(list); ! return PySequence_GetSlice(pattern, 0, 0); case 1: result = PyList_GET_ITEM(list, 0); Py_INCREF(result); I'll update the Python repository asap (once I've gotten around to merge in some changes done in the Python repository). PS. also see my post on comp.lang.python on this topic. well-written unicode code shouldn't care about things like this... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:05 Message: Logged In: YES user_id=21627 Would you like to work on a patch for this bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635398&group_id=5470 From noreply@sourceforge.net Sat Nov 9 19:03:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 11:03:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-564729 ] FixTk.py logic wrong Message-ID: Bugs item #564729, was opened at 2002-06-05 08:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470 Category: Tkinter Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Martin v. Löwis (loewis) Summary: FixTk.py logic wrong Initial Comment: The logic in FixTk.py is wrong for Tix: the Tix version number is independent of the Tk/Tcl version number. Just duplicate the Tcl code logic for Tix, and don't reuse the Tcl version number. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:03 Message: Logged In: YES user_id=21627 This was fixed in FixTk.py 1.7 and 1.5.10.2. Please provide diffs in the future. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 15:49 Message: Logged In: YES user_id=6380 Randomly assigned to Martin. Martin, can you do this? If not, assign it back to me. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:06 Message: Logged In: YES user_id=33229 Sorry for the lack of detail: the logic is wrong because the version number of Tix is assumed to be the same as the version number of Tcl in _tkinter. Right now they are different (8.3 or 8.4 for Tcl and 8.1 for Tix) and in general these days with stubs in Tcl, they are unrelated. Any Tix should work with any Tcl after Tcl 8.1 or so. So the answer is to remove tix from the for loop, and just copy the Tcl block of logic and change the tcl to tix as in the following (untested) if not os.environ.has_key("TIX_LIBRARY"): for name in os.listdir(prefix): if name.startswith("tix"): tixdir = os.path.join(prefix,name) if os.path.isdir(tixdir): os.environ["TIX_LIBRARY"] = tixdir del tixdir Note that as it stands now there is a subtle difference between the logic for setting TCL_LIBRARY and for setting TK_LIBRARY (ignoring tix completely). Imagine you have a Tcl directory with no environment variables and the following subdirs: tcl8.3 tcl8.4 tk8.3 tk8.4 If os.listddir returns the directories in alphabetical order I think you end up with TCL_LIBRARY=.../tcl8.4 (there's no break in the for name loop) and TK_LIBRARY=.../tk8.3 if tk was compiled with tcl 8.3 (_tkinter.TCL_VERSION) With Tk8.4 now finally released this a real potential scenario. This may be good or bad - the attached file maintains it. The discussion above and the attached file applies to all versions of Python, so it should be tagged for any 2.x branch. I think the same is true for Tix.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 21:25 Message: Logged In: YES user_id=6380 Can you please supply a patch? The code in 2.2 and later is different; is that still broken? If so, please supply two patches! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470 From noreply@sourceforge.net Sat Nov 9 19:09:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 11:09:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sat Nov 9 20:02:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 12:02:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sat Nov 9 20:26:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 12:26:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sat Nov 9 20:44:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 12:44:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sat Nov 9 21:09:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 13:09:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-635814 ] cStringIO().write TypeError Message-ID: Bugs item #635814, was opened at 2002-11-08 18:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: kris kvilekval (kgk) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO().write TypeError Initial Comment: There is an incompatibilty between StringIO and cStringIO, as demonstrated below.. Passing an integer to StringIO.write is OK while it not OK to pass one to cStringIO. $ python Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO >>> sfile = StringIO.StringIO() >>> sfile.write (100) >>> print sfile.getvalue() 100 >>> import cStringIO >>> cfile = cStringIO.StringIO() >>> cfile.write (100) Traceback (most recent call last): File "", line 1, in ? TypeError: write() argument 1 must be string or read-only buffer, not int >>> cfile.write (str(100)) ---------------------------------------------------------------------- >Comment By: kris kvilekval (kgk) Date: 2002-11-09 13:09 Message: Logged In: YES user_id=569286 This seems like an unnecessary incompatibility, however I guess it is there in the interest of speed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 10:04 Message: Logged In: YES user_id=21627 This is by design. The file protocol makes no guarantee that you can write objects other than strings into a file, unless the object explicitly documents the support for other objects. cStringIO differs in many ways from StringIO, this is but one way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 From noreply@sourceforge.net Sat Nov 9 21:27:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 13:27:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 22:27 Message: Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sat Nov 9 21:35:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 13:35:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-635814 ] cStringIO().write TypeError Message-ID: Bugs item #635814, was opened at 2002-11-09 03:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: kris kvilekval (kgk) >Assigned to: M.-A. Lemburg (lemburg) Summary: cStringIO().write TypeError Initial Comment: There is an incompatibilty between StringIO and cStringIO, as demonstrated below.. Passing an integer to StringIO.write is OK while it not OK to pass one to cStringIO. $ python Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO >>> sfile = StringIO.StringIO() >>> sfile.write (100) >>> print sfile.getvalue() 100 >>> import cStringIO >>> cfile = cStringIO.StringIO() >>> cfile.write (100) Traceback (most recent call last): File "", line 1, in ? TypeError: write() argument 1 must be string or read-only buffer, not int >>> cfile.write (str(100)) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 22:35 Message: Logged In: YES user_id=21627 It's a bug that StringIO accepts it. file.write does not support numbers, either. Unfortunately, this bug cannot be fixed, for backwards compatibility. The conversion of any argument to a string was originally introduced for Python 2.2, to support arbitrary buffer objects. That it also accepts numbers now was an unexpected side effect. Assigning to Marc-Andre, as he introduced that feature originally. ---------------------------------------------------------------------- Comment By: kris kvilekval (kgk) Date: 2002-11-09 22:09 Message: Logged In: YES user_id=569286 This seems like an unnecessary incompatibility, however I guess it is there in the interest of speed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:04 Message: Logged In: YES user_id=21627 This is by design. The file protocol makes no guarantee that you can write objects other than strings into a file, unless the object explicitly documents the support for other objects. cStringIO differs in many ways from StringIO, this is but one way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635814&group_id=5470 From noreply@sourceforge.net Sat Nov 9 22:43:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 14:43:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 22:43 Message: Logged In: YES user_id=76089 Umm, ok... Why is this useful? ;-) $ uname -r 2.7 $ uname -v SNOWY#0 If you're wanting to detect OpenBSD surely it's that "uname - s" == "OpenBSD"? Like I say so far as I can tell it's *all* versions of OpenBSD that have the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:27 Message: Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sat Nov 9 23:47:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Nov 2002 15:47:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-10 00:47 Message: Logged In: YES user_id=21627 "All" BSD versions means 2.x, and 3.[012], right? Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 23:43 Message: Logged In: YES user_id=76089 Umm, ok... Why is this useful? ;-) $ uname -r 2.7 $ uname -v SNOWY#0 If you're wanting to detect OpenBSD surely it's that "uname - s" == "OpenBSD"? Like I say so far as I can tell it's *all* versions of OpenBSD that have the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 22:27 Message: Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Sun Nov 10 15:45:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 07:45:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) >Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:45 Message: Logged In: YES user_id=33168 I'm pretty sure this change (between 2.2.2 and 2.3) in stringobject.c is the problem: @@ -3320,7 +3623,7 @@ arglen = -1; argidx = -2; } - if (args->ob_type->tp_as_mapping) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) dict = args; Now for non-tuples, dict is set. dict is used later on to determine if an exception should be set. This still works, ie produces the exception: (r'.po$' % "hallo",) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Sun Nov 10 15:49:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 07:49:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) >Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:49 Message: Logged In: YES user_id=33168 Let me try that again: r'.po$' % ("hallo",) The line was changed in rev 2.166 by mwh for extended slicing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:45 Message: Logged In: YES user_id=33168 I'm pretty sure this change (between 2.2.2 and 2.3) in stringobject.c is the problem: @@ -3320,7 +3623,7 @@ arglen = -1; argidx = -2; } - if (args->ob_type->tp_as_mapping) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) dict = args; Now for non-tuples, dict is set. dict is used later on to determine if an exception should be set. This still works, ie produces the exception: (r'.po$' % "hallo",) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Sun Nov 10 16:35:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 08:35:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Michael Hudson (mwh) >Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 11:35 Message: Logged In: YES user_id=33168 The problem is that string is a mapping (also changed in 2.166). The patch below fixes the problem. Michael, do you have any problem with this change? If not, I'll check it in with a test (unless you beat me to it). - if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args) && !PyString_Check(args)) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:49 Message: Logged In: YES user_id=33168 Let me try that again: r'.po$' % ("hallo",) The line was changed in rev 2.166 by mwh for extended slicing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:45 Message: Logged In: YES user_id=33168 I'm pretty sure this change (between 2.2.2 and 2.3) in stringobject.c is the problem: @@ -3320,7 +3623,7 @@ arglen = -1; argidx = -2; } - if (args->ob_type->tp_as_mapping) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) dict = args; Now for non-tuples, dict is set. dict is used later on to determine if an exception should be set. This still works, ie produces the exception: (r'.po$' % "hallo",) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Sun Nov 10 19:48:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 11:48:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-636313 ] --with-dl-dld section of the readme Message-ID: Bugs item #636313, was opened at 2002-11-10 13:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636313&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: --with-dl-dld section of the readme Initial Comment: [Related to question that was asked on python-help] The --with-dl-dld section of the readme could probably come out. The URLs in it point to files that don't exist any longer and the chances of fixing them seems small since pretty well the only references that Google finds to dl-dld-1.1.tar.Z are to copies of the README. Even if the files could be found, the number of people who want to fake up dynamic linking on platforms that don't support it natively is probably pretty small these days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636313&group_id=5470 From noreply@sourceforge.net Mon Nov 11 02:16:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 18:16:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-11 02:16 Message: Logged In: YES user_id=76089 The patch nearly works. The line "if test $define_xopen_source=yes" you have added to configure should read "if test $define_xopen_source = yes" (i.e. with spaces around the equals sign). With the patch, amended, it fixes the problem. Please though could you change it to 'OpenBSD/*' instead of 'OpenBSD/2.*' and 'OpenBSD/3.[012]'? I think it is much more likely to cause problems in the future that _XOPEN_SOURCE *is* defined in the as-yet- hypothetical OpenBSD/3.3 than if it were not defined since I don't suspect that OpenBSD will suddenly start requiring people to define this value that would break compatibility with all older OpenBSDs ;-) Many thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 23:47 Message: Logged In: YES user_id=21627 "All" BSD versions means 2.x, and 3.[012], right? Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 22:43 Message: Logged In: YES user_id=76089 Umm, ok... Why is this useful? ;-) $ uname -r 2.7 $ uname -v SNOWY#0 If you're wanting to detect OpenBSD surely it's that "uname - s" == "OpenBSD"? Like I say so far as I can tell it's *all* versions of OpenBSD that have the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:27 Message: Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 20:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 19:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Mon Nov 11 02:30:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 18:30:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-636431 ] ./configure test socklen_t fails on *BSD Message-ID: Bugs item #636431, was opened at 2002-11-11 02:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure test socklen_t fails on *BSD Initial Comment: Context: the patch applied updating CVS version 1.121 of configure.in to version 1.122. This code is broken. Yes I know that was over 2 years ago! I am somewhat bemused it hasn't been noticed before. The patch adds #include to confdefs.h. This is broken because it means becomes the first header to be #included during the test for socklen_t, and it is illegal on *BSD to include before . The upshot of this is that pyconfig.h ends up #defining socklen_t, which then means that when is #included while building Python all sorts of compiler diagnostics are generated, and god-only-knows what the effect on the resulting binary is, and obviously the correct definition for socklen_t is not being used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 From noreply@sourceforge.net Mon Nov 11 02:31:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 18:31:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-636431 ] ./configure test socklen_t fails on *BSD Message-ID: Bugs item #636431, was opened at 2002-11-11 02:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure test socklen_t fails on *BSD Initial Comment: Context: the patch applied updating CVS version 1.121 of configure.in to version 1.122. This code is broken. Yes I know that was over 2 years ago! I am somewhat bemused it hasn't been noticed before. The patch adds #include to confdefs.h. This is broken because it means becomes the first header to be #included during the test for socklen_t, and it is illegal on *BSD to include before . The upshot of this is that pyconfig.h ends up #defining socklen_t, which then means that when is #included while building Python all sorts of compiler diagnostics are generated, and god-only-knows what the effect on the resulting binary is, and obviously the correct definition for socklen_t is not being used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 From noreply@sourceforge.net Mon Nov 11 06:01:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 22:01:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 07:01 Message: Logged In: YES user_id=21627 I won't implement a blanket change for all future OpenBSD versions. I don't expect that OpenBSD will *require* definition of _XOPEN_SOURCE, either, but I do hope that they provide a mechanism to request extensions some day. So this change will need to be re-evaluated for each OpenBSD release. I hope that Python can remove all these system-specific changes, over time. This can't happen until we stop support OpenBSD 3.2, but we do need to record what versions of OpenBSD are affected, and we do need actual proof that they are affected, and that no alternative solution is available. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-11 03:16 Message: Logged In: YES user_id=76089 The patch nearly works. The line "if test $define_xopen_source=yes" you have added to configure should read "if test $define_xopen_source = yes" (i.e. with spaces around the equals sign). With the patch, amended, it fixes the problem. Please though could you change it to 'OpenBSD/*' instead of 'OpenBSD/2.*' and 'OpenBSD/3.[012]'? I think it is much more likely to cause problems in the future that _XOPEN_SOURCE *is* defined in the as-yet- hypothetical OpenBSD/3.3 than if it were not defined since I don't suspect that OpenBSD will suddenly start requiring people to define this value that would break compatibility with all older OpenBSDs ;-) Many thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-10 00:47 Message: Logged In: YES user_id=21627 "All" BSD versions means 2.x, and 3.[012], right? Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 23:43 Message: Logged In: YES user_id=76089 Umm, ok... Why is this useful? ;-) $ uname -r 2.7 $ uname -v SNOWY#0 If you're wanting to detect OpenBSD surely it's that "uname - s" == "OpenBSD"? Like I say so far as I can tell it's *all* versions of OpenBSD that have the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 22:27 Message: Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Mon Nov 11 06:39:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Nov 2002 22:39:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-636485 ] undefined SSL_ERROR_EOF in SSLFile._read Message-ID: Bugs item #636485, was opened at 2002-11-11 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: undefined SSL_ERROR_EOF in SSLFile._read Initial Comment: File "c:\Python22\lib\httplib.py", line 840, in _read if (err[0] == socket.SSL_ERROR_ZERO_RETURN AttributeError: 'module' object has no attribute 'SSL_ERROR_EOF' Traceback (most recent call last): tested: Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin and Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 with http://www.cs.fhm.edu/~ifw00065/pyssl/index.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 From noreply@sourceforge.net Mon Nov 11 10:29:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 02:29:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 17:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Neal Norwitz (nnorwitz) >Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-11 10:29 Message: Logged In: YES user_id=6656 You're right. Please do add a test! Also note that unicode's are mappings too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 16:35 Message: Logged In: YES user_id=33168 The problem is that string is a mapping (also changed in 2.166). The patch below fixes the problem. Michael, do you have any problem with this change? If not, I'll check it in with a test (unless you beat me to it). - if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args) && !PyString_Check(args)) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 15:49 Message: Logged In: YES user_id=33168 Let me try that again: r'.po$' % ("hallo",) The line was changed in rev 2.166 by mwh for extended slicing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 15:45 Message: Logged In: YES user_id=33168 I'm pretty sure this change (between 2.2.2 and 2.3) in stringobject.c is the problem: @@ -3320,7 +3623,7 @@ arglen = -1; argidx = -2; } - if (args->ob_type->tp_as_mapping) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) dict = args; Now for non-tuples, dict is set. dict is used later on to determine if an exception should be set. This still works, ie produces the exception: (r'.po$' % "hallo",) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Mon Nov 11 11:50:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 03:50:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 08:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Michael Hudson (mwh) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-11 11:50 Message: Logged In: YES user_id=6656 I've thought about this a bit. You're writing a NSArray proxy, right? Here's some advice: do NOT inherit from list. What does inheriting from list get you? The ability to pass `PyList_Check'. But almost inevitably code that calls that promptly pokes into the internal structure of the list. For example, you'll find iterating over your proxy list doesn't respect the subtype (unless you supply an __iter__ method, I guess/hope). If you find things that fail because of this, let's fix those to take more general sequences. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-06 11:21 Message: Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 08:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 18:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 11:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Mon Nov 11 12:27:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 04:27:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 09:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Michael Hudson (mwh) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-11 13:26 Message: Logged In: YES user_id=580910 I already have an NSArray proxy (actually a module that proxies the entire Cocoa classtree on MacOS X). The NSArray proxy is not a subclass of list but part of a class hierarchy that mirrors that of the proxied classes (the code is available from pyobjc.sourceforge.net). The reason I ran into this bug is that someone suggested that subclassing list might be a good solution for using an NSArray as the source for slice assigment on lists. Thanks to your previous patch that is no longer an issue. It might be usefull to add functions that check if it is save to directly access the list representation. Even though it might not be sensible to do so, it is possible to change __getitem__ et. al. from Python code and it would be very strange if the version of those methods from subclasses is sometimes ignored. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-11 12:50 Message: Logged In: YES user_id=6656 I've thought about this a bit. You're writing a NSArray proxy, right? Here's some advice: do NOT inherit from list. What does inheriting from list get you? The ability to pass `PyList_Check'. But almost inevitably code that calls that promptly pokes into the internal structure of the list. For example, you'll find iterating over your proxy list doesn't respect the subtype (unless you supply an __iter__ method, I guess/hope). If you find things that fail because of this, let's fix those to take more general sequences. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-06 12:21 Message: Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 09:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 19:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 12:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Mon Nov 11 13:30:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 05:30:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD Message-ID: Bugs item #635034, was opened at 2002-11-07 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _XOPEN_SOURCE on OpenBSD Initial Comment: Defining _XOPEN_SOURCE on OpenBSD breaks many things. For example, it makes the select and time modules unavailable (*oops*). I think this is probably a bug in OpenBSD (I have bugreported it there) but in the absence of the ability to fix the bug in every OpenBSD installation in the world it would be nice if Python would detect OpenBSD and not define _XOPEN_SOURCE. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:30 Message: Logged In: YES user_id=21627 Committed as configure 1.355 configure.in 1.366 pyconfig.h.in 1.58 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 07:01 Message: Logged In: YES user_id=21627 I won't implement a blanket change for all future OpenBSD versions. I don't expect that OpenBSD will *require* definition of _XOPEN_SOURCE, either, but I do hope that they provide a mechanism to request extensions some day. So this change will need to be re-evaluated for each OpenBSD release. I hope that Python can remove all these system-specific changes, over time. This can't happen until we stop support OpenBSD 3.2, but we do need to record what versions of OpenBSD are affected, and we do need actual proof that they are affected, and that no alternative solution is available. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-11 03:16 Message: Logged In: YES user_id=76089 The patch nearly works. The line "if test $define_xopen_source=yes" you have added to configure should read "if test $define_xopen_source = yes" (i.e. with spaces around the equals sign). With the patch, amended, it fixes the problem. Please though could you change it to 'OpenBSD/*' instead of 'OpenBSD/2.*' and 'OpenBSD/3.[012]'? I think it is much more likely to cause problems in the future that _XOPEN_SOURCE *is* defined in the as-yet- hypothetical OpenBSD/3.3 than if it were not defined since I don't suspect that OpenBSD will suddenly start requiring people to define this value that would break compatibility with all older OpenBSDs ;-) Many thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-10 00:47 Message: Logged In: YES user_id=21627 "All" BSD versions means 2.x, and 3.[012], right? Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 23:43 Message: Logged In: YES user_id=76089 Umm, ok... Why is this useful? ;-) $ uname -r 2.7 $ uname -v SNOWY#0 If you're wanting to detect OpenBSD surely it's that "uname - s" == "OpenBSD"? Like I say so far as I can tell it's *all* versions of OpenBSD that have the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 22:27 Message: Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:44 Message: Logged In: YES user_id=76089 Don't be irritating. Of course the header files don't change, but through the use of #if statements what they do *does* change. My statement is perfectly correct, the definitions are indeed still there but they are "not available" like I said. Here is a URL for the very latest sys/types.h: http://www.openbsd.org/cgi- bin/cvsweb/~checkout~/src/sys/sys/types.h? rev=1.18&content-type=text/plain Search for "fd_set". You will see that it is in a #if section as follows: #if !defined(_POSIX_SOURCE) && !defined (_XOPEN_SOURCE) select() itself comes from unistd.h, and is inside: #if !defined(_XOPEN_SOURCE) No, I don't know why these #if statements are there, they seem completely stupid, but there we go. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 21:26 Message: Logged In: YES user_id=21627 Your statement "are simply not available in any header file" is factually incorrect: none of the header files change on disk by defining something, so the definitions are still in the header files. Can you please attach the header file that normally carries select? > Why is _XOPEN_SOURCE being defined anyway? Because many systems require it, for conformance. POSIX mandates that you define it, if you want to use system interface that are specified by more recent POSIX releases, see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html In particular, many features of HP-UX are not available unless you define _XOPEN_SOURCE, the same holds for the various SCO Unices. ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-09 21:02 Message: Logged In: YES user_id=76089 It would be a great deal of effort to make separate bug reports (I would have to individually test every Python feature by hand), and it wouldn't gain anything. The problem is that OpenBSD is buggy, has been since version 2.0 and still is in the very latest CVS. For example, if you define _XOPEN_SOURCE (its value doesn't make any difference, just if it is defined) then there is absolutely no way to get the select(), fd_set, etc, they are simply not available in any header file. You can't use select() in a C program that #defines _XOPEN_SOURCE. I don't see why you say there is "no way" to withdraw the definition of _XOPEN_SOURCE - instead of making the addition of _XOPEN_SOURCE to the header file unconditional, simply detect OpenBSD in ./configure and don't define it in that case. Why is that difficult? Why is _XOPEN_SOURCE being defined anyway? Because it breaks everything so badly on OpenBSD, and nobody has noticed this before, I am suspecting that almost no programs out there except Python define it. This makes it likely to break things on many different platforms. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 20:09 Message: Logged In: YES user_id=21627 You need to provide more details. For the moment, I see *no way* to withdraw the definition of _XOPEN_SOURCE, not even for OpenBSD. Please make separate bug reports for each issue, perhaps starting with the select module. Why is it unavailable? select *is* a feature of POSIX, after all (as is poll). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470 From noreply@sourceforge.net Mon Nov 11 13:50:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 05:50:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-636431 ] ./configure test socklen_t fails on *BSD Message-ID: Bugs item #636431, was opened at 2002-11-11 03:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure test socklen_t fails on *BSD Initial Comment: Context: the patch applied updating CVS version 1.121 of configure.in to version 1.122. This code is broken. Yes I know that was over 2 years ago! I am somewhat bemused it hasn't been noticed before. The patch adds #include to confdefs.h. This is broken because it means becomes the first header to be #included during the test for socklen_t, and it is illegal on *BSD to include before . The upshot of this is that pyconfig.h ends up #defining socklen_t, which then means that when is #included while building Python all sorts of compiler diagnostics are generated, and god-only-knows what the effect on the resulting binary is, and obviously the correct definition for socklen_t is not being used. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:50 Message: Logged In: YES user_id=21627 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 From noreply@sourceforge.net Mon Nov 11 13:52:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 05:52:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-636485 ] undefined SSL_ERROR_EOF in SSLFile._read Message-ID: Bugs item #636485, was opened at 2002-11-11 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: undefined SSL_ERROR_EOF in SSLFile._read Initial Comment: File "c:\Python22\lib\httplib.py", line 840, in _read if (err[0] == socket.SSL_ERROR_ZERO_RETURN AttributeError: 'module' object has no attribute 'SSL_ERROR_EOF' Traceback (most recent call last): tested: Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin and Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 with http://www.cs.fhm.edu/~ifw00065/pyssl/index.html ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:52 Message: Logged In: YES user_id=21627 That is very strange. Can you please report all symbols in module socket that start with SSL_ERROR_? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 From noreply@sourceforge.net Mon Nov 11 14:45:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 06:45:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-636431 ] ./configure test socklen_t fails on *BSD Message-ID: Bugs item #636431, was opened at 2002-11-11 02:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure test socklen_t fails on *BSD Initial Comment: Context: the patch applied updating CVS version 1.121 of configure.in to version 1.122. This code is broken. Yes I know that was over 2 years ago! I am somewhat bemused it hasn't been noticed before. The patch adds #include to confdefs.h. This is broken because it means becomes the first header to be #included during the test for socklen_t, and it is illegal on *BSD to include before . The upshot of this is that pyconfig.h ends up #defining socklen_t, which then means that when is #included while building Python all sorts of compiler diagnostics are generated, and god-only-knows what the effect on the resulting binary is, and obviously the correct definition for socklen_t is not being used. ---------------------------------------------------------------------- >Comment By: Jon Ribbens (jribbens) Date: 2002-11-11 14:45 Message: Logged In: YES user_id=76089 The patch is slightly broken, it is including sys/socket.h twice instead of sys/types.h. With that typo fixed it works fine and solves the problem. Many thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 13:50 Message: Logged In: YES user_id=21627 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 From noreply@sourceforge.net Mon Nov 11 14:59:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 06:59:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-636431 ] ./configure test socklen_t fails on *BSD Message-ID: Bugs item #636431, was opened at 2002-11-11 03:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure test socklen_t fails on *BSD Initial Comment: Context: the patch applied updating CVS version 1.121 of configure.in to version 1.122. This code is broken. Yes I know that was over 2 years ago! I am somewhat bemused it hasn't been noticed before. The patch adds #include to confdefs.h. This is broken because it means becomes the first header to be #included during the test for socklen_t, and it is illegal on *BSD to include before . The upshot of this is that pyconfig.h ends up #defining socklen_t, which then means that when is #included while building Python all sorts of compiler diagnostics are generated, and god-only-knows what the effect on the resulting binary is, and obviously the correct definition for socklen_t is not being used. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 15:59 Message: Logged In: YES user_id=21627 Committed as configure 1.357 configure.in 1.368 pyconfig.h.in 1.60 ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-11-11 15:45 Message: Logged In: YES user_id=76089 The patch is slightly broken, it is including sys/socket.h twice instead of sys/types.h. With that typo fixed it works fine and solves the problem. Many thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:50 Message: Logged In: YES user_id=21627 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636431&group_id=5470 From noreply@sourceforge.net Mon Nov 11 16:01:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 08:01:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-636648 ] os.path.normpath leading '//' Message-ID: Bugs item #636648, was opened at 2002-11-11 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Jones (carpaski) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.normpath leading '//' Initial Comment: normpath does not remove leading double slashes. (Linux) Python 2.2.1 (#1, Oct 30 2002, 19:46:40) >>> import os.path >>> os.path.normpath("//usr/bin") '//usr/bin' >>> os.path.normpath("///usr/bin") '/usr/bin' >>> os.path.normpath("//./usr/bin") '//usr/bin' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 From noreply@sourceforge.net Mon Nov 11 17:09:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 09:09:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-636685 ] ftplib bails out on empty responses Message-ID: Bugs item #636685, was opened at 2002-11-11 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib bails out on empty responses Initial Comment: In ftplib.py, FTP.getresp(), there is: if c in '123', and c is the first char of the reponse line. However, if the response is empty, then this line will throw an exception: File "/usr/lib/python2.2/ftplib.py", line 108, in __init__ self.connect(host) File "/usr/lib/python2.2/ftplib.py", line 133, in connect self.welcome = self.getresp() File "/usr/lib/python2.2/ftplib.py", line 216, in getresp if c not in '123': TypeError: 'in ' requires character as left operand System info: LinkChecker 1.6.6 Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 I suggest you test if c is a character before calling the if-clause. Cheers, Bastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 From noreply@sourceforge.net Mon Nov 11 17:12:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 09:12:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-531145 ] socket.sslerror is not a socket.error Message-ID: Bugs item #531145, was opened at 2002-03-18 00:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: socket.sslerror is not a socket.error Initial Comment: Python 2.1.2 (#1, Mar 16 2002, 00:56:55) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import socket >>> socket.sslerror >>> try: raise socket.sslerror ... except socket.error: pass ... Traceback (most recent call last): File "", line 1, in ? socket.sslerror >>> ---------------------------------------------------------------------- >Comment By: Bastian Kleineidam (calvin) Date: 2002-11-11 18:12 Message: Logged In: YES user_id=9205 Yes, I want socket.sslerror to be a subclass of socket.error. It simplifies code layout (see my previous answer) and it follows the documentation. And yes, its work, but only a little :) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-05 02:05 Message: Logged In: YES user_id=163326 So do you propose to make socket.sslerror a subclass of socket.error. Is this desirable? I'm not sure. Is it work? Yes. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-03-18 21:23 Message: Logged In: YES user_id=9205 The documentation says for socket.error: "This exception is raised for socket- or address-related errors." I think socket.sslerror is such an error, because then you can write try: sock.write("") # could be ssl-socket except socket.error: pass The other way would be _exceptions = [socket.error] if hasattr(socket, "sslerror"): _exceptions.append(socket.sslerror) try: sock.write("") except _exceptions: pass Anyway, I assume this is a minor "bug". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-18 11:44 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470 From noreply@sourceforge.net Mon Nov 11 17:26:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 09:26:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-636485 ] undefined SSL_ERROR_EOF in SSLFile._read Message-ID: Bugs item #636485, was opened at 2002-11-11 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: undefined SSL_ERROR_EOF in SSLFile._read Initial Comment: File "c:\Python22\lib\httplib.py", line 840, in _read if (err[0] == socket.SSL_ERROR_ZERO_RETURN AttributeError: 'module' object has no attribute 'SSL_ERROR_EOF' Traceback (most recent call last): tested: Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin and Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 with http://www.cs.fhm.edu/~ifw00065/pyssl/index.html ---------------------------------------------------------------------- >Comment By: Michael Scharf (scharf) Date: 2002-11-11 18:26 Message: Logged In: YES user_id=71965 on cygwin: SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN on win32 (the same): SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:52 Message: Logged In: YES user_id=21627 That is very strange. Can you please report all symbols in module socket that start with SSL_ERROR_? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 From noreply@sourceforge.net Mon Nov 11 17:52:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 09:52:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-636485 ] undefined SSL_ERROR_EOF in SSLFile._read Message-ID: Bugs item #636485, was opened at 2002-11-11 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: undefined SSL_ERROR_EOF in SSLFile._read Initial Comment: File "c:\Python22\lib\httplib.py", line 840, in _read if (err[0] == socket.SSL_ERROR_ZERO_RETURN AttributeError: 'module' object has no attribute 'SSL_ERROR_EOF' Traceback (most recent call last): tested: Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin and Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 with http://www.cs.fhm.edu/~ifw00065/pyssl/index.html ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 18:52 Message: Logged In: YES user_id=21627 By "win32", do you mean the PythonLabs binary? This does not support OpenSSL (and defines no SSL_ERROR_ constants at all), so it is not clear to me what binary you are using. Same for Cygwin. Python 2.2 has this code PyModule_AddIntConstant(m, "SSL_ERROR_SSL", PY_SSL_ERROR_SSL); PyModule_AddIntConstant(m, "SSL_ERROR_WANT_CONNECT", PY_SSL_ERROR_WANT_CONNECT); /* non ssl.h errorcodes */ PyModule_AddIntConstant(m, "SSL_ERROR_EOF", PY_SSL_ERROR_EOF); So there is absolutely *no* way that SSL_ERROR_SSL is defined, but SSL_ERROR_EOF is not - unless somebody modified the source code. ---------------------------------------------------------------------- Comment By: Michael Scharf (scharf) Date: 2002-11-11 18:26 Message: Logged In: YES user_id=71965 on cygwin: SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN on win32 (the same): SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:52 Message: Logged In: YES user_id=21627 That is very strange. Can you please report all symbols in module socket that start with SSL_ERROR_? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 From noreply@sourceforge.net Tue Nov 12 01:31:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 17:31:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-481896 ] popen3 file objects hanging Message-ID: Bugs item #481896, was opened at 2001-11-14 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=481896&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 file objects hanging Initial Comment: RE:#210676 System: Python 2.0 on solaris 8 The above bug is reported closed but I cannot see why. >>> sub = popen2.Popen3(cmd,1) >>> sub.fromchild.readlines() # blocked on stderr As reported in the above sited bug report, we too are suffering from this behaviour on file objects returned by popen3. It does appear that the stderr buffer is filling (the app writes a lot of stuff to stderr) and blocking stdout, but i cannot seem to flush the buffer. I need to acquire both stderr and stdout data. I have tried setting the bufsize to 0 (unbuffered) but that doesn't work. I have made the buffer big, but nothing there. Might there be some magic bufsize? popen4 (which stuffs both stderr and stdout into one file object) works perfectly as there is no blocking. Reading through the bugs about popen3, the bug report above is exactly what we are experiencing. The "solution" offered is not a solution at all. We are running 3rd party code, i.e. we can't close stderr inside the application, nor would we want to. stderr and stdout file descriptors must remain open for the duration of the application. Has there been some viable solution to this which has not been documented? ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 01:31 Message: Logged In: YES user_id=7887 You can workaround the problem in the following ways: 1) as martin explained in the previous mentioned bug; 2) using non-blocking I/O: fd = pop.childerr.fileno() flags = fcntl.fcntl (fd, fcntl.F_GETFL, 0) flags = flags | os.O_NONBLOCK fcntl.fcntl (fd, fcntl.F_SETFL, flags) 3) piping the child error into /dev/null, if you don't want it. Either way, IMO that's something which belongs to how the operating system deals with that, since there's no way for Python to guess what you'd expect it to do in all possible cases, and it probably shouldn't try to. I suggest closing that bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=481896&group_id=5470 From noreply@sourceforge.net Tue Nov 12 03:13:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 19:13:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-636485 ] undefined SSL_ERROR_EOF in SSLFile._read Message-ID: Bugs item #636485, was opened at 2002-11-11 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: undefined SSL_ERROR_EOF in SSLFile._read Initial Comment: File "c:\Python22\lib\httplib.py", line 840, in _read if (err[0] == socket.SSL_ERROR_ZERO_RETURN AttributeError: 'module' object has no attribute 'SSL_ERROR_EOF' Traceback (most recent call last): tested: Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin and Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 with http://www.cs.fhm.edu/~ifw00065/pyssl/index.html ---------------------------------------------------------------------- >Comment By: Michael Scharf (scharf) Date: 2002-11-12 04:13 Message: Logged In: YES user_id=71965 I use the normal win32 python distribution http://www.python.org/ftp/python/2.2.2/Python-2.2.2.exe For cygwin I use the python2.2.1 (the one that the cygwin-setup installes) >From http://pyopenssl.sourceforge.net/ I have instelled: http://prdownloads.sourceforge.net/pyopenssl/pyOpenSSL-0.4.1.win32-py2.2.exe?download It seems that the cygwin python uses the same ssl implementation. So the bug is probably in pyopenssl. Here is MY cygwin output: $ python Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> filter(lambda x:x.find("SSL_")==0,dir(socket)) ['SSL_ERROR_SSL', 'SSL_ERROR_SYSCALL', 'SSL_ERROR_WANT_READ', 'SSL_ERROR_WANT_WRITE', 'SSL_ERROR_WANT_X509_LOOKUP', 'SSL_ERROR_ZERO_RETURN'] looking into the sourcecode of http://prdownloads.sourceforge.net/pyopenssl/pyOpenSSL-0.5.1.tar.gz?download and http://prdownloads.sourceforge.net/pyopenssl/pyOpenSSL-0.4.1.tar.gz?download in file file src/ssl/ssl.c: /* * ADD_EXCEPTION(dict,name,base) expands to a correct Exception declaration, * inserting OpenSSL.SSL.name into dict, derviving the exception from base. */ #define ADD_EXCEPTION(_name, _base) \ do { \ ssl_##_name = PyErr_NewException("SSL."#_name, _base, NULL);\ if (ssl_##_name == NULL) \ goto error; \ if (PyModule_AddObject(module, #_name, ssl_##_name) != 0) \ goto error; \ } while (0) ssl_Error = PyErr_NewException("SSL.Error", NULL, NULL); if (ssl_Error == NULL) goto error; if (PyModule_AddObject(module, "Error", ssl_Error) != 0) goto error; ADD_EXCEPTION(ZeroReturnError, ssl_Error); ADD_EXCEPTION(WantReadError, ssl_Error); ADD_EXCEPTION(WantWriteError, ssl_Error); ADD_EXCEPTION(WantX509LookupError, ssl_Error); ADD_EXCEPTION(SysCallError, ssl_Error); #undef ADD_EXCEPTION Which version of SSL is your code snippet taken from? I did not know that there are multipe OpenSSL for python. So, maybe I should report the bug to http://pyopenssl.sourceforge.net ... Michael ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 18:52 Message: Logged In: YES user_id=21627 By "win32", do you mean the PythonLabs binary? This does not support OpenSSL (and defines no SSL_ERROR_ constants at all), so it is not clear to me what binary you are using. Same for Cygwin. Python 2.2 has this code PyModule_AddIntConstant(m, "SSL_ERROR_SSL", PY_SSL_ERROR_SSL); PyModule_AddIntConstant(m, "SSL_ERROR_WANT_CONNECT", PY_SSL_ERROR_WANT_CONNECT); /* non ssl.h errorcodes */ PyModule_AddIntConstant(m, "SSL_ERROR_EOF", PY_SSL_ERROR_EOF); So there is absolutely *no* way that SSL_ERROR_SSL is defined, but SSL_ERROR_EOF is not - unless somebody modified the source code. ---------------------------------------------------------------------- Comment By: Michael Scharf (scharf) Date: 2002-11-11 18:26 Message: Logged In: YES user_id=71965 on cygwin: SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN on win32 (the same): SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:52 Message: Logged In: YES user_id=21627 That is very strange. Can you please report all symbols in module socket that start with SSL_ERROR_? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 From noreply@sourceforge.net Tue Nov 12 05:19:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 21:19:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius Gedminas (mgedmin) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Tue Nov 12 06:00:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Nov 2002 22:00:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-636485 ] undefined SSL_ERROR_EOF in SSLFile._read Message-ID: Bugs item #636485, was opened at 2002-11-11 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: undefined SSL_ERROR_EOF in SSLFile._read Initial Comment: File "c:\Python22\lib\httplib.py", line 840, in _read if (err[0] == socket.SSL_ERROR_ZERO_RETURN AttributeError: 'module' object has no attribute 'SSL_ERROR_EOF' Traceback (most recent call last): tested: Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin and Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 with http://www.cs.fhm.edu/~ifw00065/pyssl/index.html ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 07:00 Message: Logged In: YES user_id=21627 My code snippet is from the Python 2.2.2 source code, from Modules/socketmodule.c. This code is not used on Windows, but httplib is designed to work with it (on Unix). So this is clearly a bug in pyopenssl. Closing as third-party. ---------------------------------------------------------------------- Comment By: Michael Scharf (scharf) Date: 2002-11-12 04:13 Message: Logged In: YES user_id=71965 I use the normal win32 python distribution http://www.python.org/ftp/python/2.2.2/Python-2.2.2.exe For cygwin I use the python2.2.1 (the one that the cygwin-setup installes) >From http://pyopenssl.sourceforge.net/ I have instelled: http://prdownloads.sourceforge.net/pyopenssl/pyOpenSSL-0.4.1.win32-py2.2.exe?download It seems that the cygwin python uses the same ssl implementation. So the bug is probably in pyopenssl. Here is MY cygwin output: $ python Python 2.2.1 (#1, Jun 25 2002, 10:55:46) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> filter(lambda x:x.find("SSL_")==0,dir(socket)) ['SSL_ERROR_SSL', 'SSL_ERROR_SYSCALL', 'SSL_ERROR_WANT_READ', 'SSL_ERROR_WANT_WRITE', 'SSL_ERROR_WANT_X509_LOOKUP', 'SSL_ERROR_ZERO_RETURN'] looking into the sourcecode of http://prdownloads.sourceforge.net/pyopenssl/pyOpenSSL-0.5.1.tar.gz?download and http://prdownloads.sourceforge.net/pyopenssl/pyOpenSSL-0.4.1.tar.gz?download in file file src/ssl/ssl.c: /* * ADD_EXCEPTION(dict,name,base) expands to a correct Exception declaration, * inserting OpenSSL.SSL.name into dict, derviving the exception from base. */ #define ADD_EXCEPTION(_name, _base) \ do { \ ssl_##_name = PyErr_NewException("SSL."#_name, _base, NULL);\ if (ssl_##_name == NULL) \ goto error; \ if (PyModule_AddObject(module, #_name, ssl_##_name) != 0) \ goto error; \ } while (0) ssl_Error = PyErr_NewException("SSL.Error", NULL, NULL); if (ssl_Error == NULL) goto error; if (PyModule_AddObject(module, "Error", ssl_Error) != 0) goto error; ADD_EXCEPTION(ZeroReturnError, ssl_Error); ADD_EXCEPTION(WantReadError, ssl_Error); ADD_EXCEPTION(WantWriteError, ssl_Error); ADD_EXCEPTION(WantX509LookupError, ssl_Error); ADD_EXCEPTION(SysCallError, ssl_Error); #undef ADD_EXCEPTION Which version of SSL is your code snippet taken from? I did not know that there are multipe OpenSSL for python. So, maybe I should report the bug to http://pyopenssl.sourceforge.net ... Michael ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 18:52 Message: Logged In: YES user_id=21627 By "win32", do you mean the PythonLabs binary? This does not support OpenSSL (and defines no SSL_ERROR_ constants at all), so it is not clear to me what binary you are using. Same for Cygwin. Python 2.2 has this code PyModule_AddIntConstant(m, "SSL_ERROR_SSL", PY_SSL_ERROR_SSL); PyModule_AddIntConstant(m, "SSL_ERROR_WANT_CONNECT", PY_SSL_ERROR_WANT_CONNECT); /* non ssl.h errorcodes */ PyModule_AddIntConstant(m, "SSL_ERROR_EOF", PY_SSL_ERROR_EOF); So there is absolutely *no* way that SSL_ERROR_SSL is defined, but SSL_ERROR_EOF is not - unless somebody modified the source code. ---------------------------------------------------------------------- Comment By: Michael Scharf (scharf) Date: 2002-11-11 18:26 Message: Logged In: YES user_id=71965 on cygwin: SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN on win32 (the same): SSL_ERROR_SSL SSL_ERROR_SYSCALL SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE SSL_ERROR_WANT_X509_LOOKUP SSL_ERROR_ZERO_RETURN ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-11 14:52 Message: Logged In: YES user_id=21627 That is very strange. Can you please report all symbols in module socket that start with SSL_ERROR_? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636485&group_id=5470 From noreply@sourceforge.net Tue Nov 12 11:45:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 03:45:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-12 12:45 Message: Logged In: YES user_id=89016 OK, checked in as: Modules/selectmodule.c 2.71 But this only works as long as the nb_int slot really returns ints, as PyInt_AsLong() can't handle a nb_int slot that returns long. Can we close the bug now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 02:33 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-08 02:09 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-08 00:03 Message: Logged In: YES user_id=89016 The attached patch diffselect.txt should fix the select module. I'm not so sure, whether the check should be PyInt_Check or PyInt_CheckExact. What should be used instead of the PyNumber_Check() call? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 23:37 Message: Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 23:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 23:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 19:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 19:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 17:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 17:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 15:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Tue Nov 12 12:24:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 04:24:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 13:09:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 05:09:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work Message-ID: Bugs item #629989, was opened at 2002-10-28 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 Category: Type/class unification Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Walter Dörwald (doerwalter) >Summary: int("123123123123123123") doesn't work Initial Comment: Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-12 06:45 Message: Logged In: YES user_id=89016 OK, checked in as: Modules/selectmodule.c 2.71 But this only works as long as the nb_int slot really returns ints, as PyInt_AsLong() can't handle a nb_int slot that returns long. Can we close the bug now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:33 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 20:09 Message: Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 18:03 Message: Logged In: YES user_id=89016 The attached patch diffselect.txt should fix the select module. I'm not so sure, whether the check should be PyInt_Check or PyInt_CheckExact. What should be used instead of the PyNumber_Check() call? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:37 Message: Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 17:26 Message: Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 17:07 Message: Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-07 13:48 Message: Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 13:33 Message: Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 11:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-06 11:00 Message: Logged In: YES user_id=6380 If it works, check it in. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-06 09:27 Message: Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470 From noreply@sourceforge.net Tue Nov 12 14:58:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 06:58:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:20:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:20:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:22:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:22:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-636685 ] ftplib bails out on empty responses Message-ID: Bugs item #636685, was opened at 2002-11-11 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib bails out on empty responses Initial Comment: In ftplib.py, FTP.getresp(), there is: if c in '123', and c is the first char of the reponse line. However, if the response is empty, then this line will throw an exception: File "/usr/lib/python2.2/ftplib.py", line 108, in __init__ self.connect(host) File "/usr/lib/python2.2/ftplib.py", line 133, in connect self.welcome = self.getresp() File "/usr/lib/python2.2/ftplib.py", line 216, in getresp if c not in '123': TypeError: 'in ' requires character as left operand System info: LinkChecker 1.6.6 Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 I suggest you test if c is a character before calling the if-clause. Cheers, Bastian ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:22 Message: Logged In: YES user_id=21627 Can you please explain in what case the server is supposed to send an empty response? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:28:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:28:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-636313 ] --with-dl-dld section of the readme Message-ID: Bugs item #636313, was opened at 2002-11-10 20:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636313&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) >Assigned to: Martin v. Löwis (loewis) Summary: --with-dl-dld section of the readme Initial Comment: [Related to question that was asked on python-help] The --with-dl-dld section of the readme could probably come out. The URLs in it point to files that don't exist any longer and the chances of fixing them seems small since pretty well the only references that Google finds to dl-dld-1.1.tar.Z are to copies of the README. Even if the files could be found, the number of people who want to fake up dynamic linking on platforms that don't support it natively is probably pretty small these days. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:27 Message: Logged In: YES user_id=21627 If so, we should probably deprecate --with-dl-dld. I have added this to PEP 11, which means that a deprecation notice will be added in Python 2.3, with the feature being removed in Python 2.4. I'll leave this report open; when I get to incorporating all deprecated features into configure, I will add a notice into the README as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636313&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:34:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:34:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher Message-ID: Bugs item #453523, was opened at 2001-08-20 22:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 1 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: list.sort crasher Initial Comment: The marshal module is on the default list of ok builtin modules, but it can be used to crash the interpreter. The new module, on the other hand, is not allowed. To me the only obvious reason for this is that it provides a way to make new code objects, which can then crash the interpreter. But marshal also gives this ability. Example is attached as a file. Having imported marshal, I use marshal.loads() on a carefully constructed string to get a corrupt code object. To work out this string: (in unrestricted mode) def f(): pass import marshal badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N', '(\x00\x00\x00\x00') which when loaded gives a code object with co_consts = (). Possible fixes: Easy: remove marshal from the list of approved modules for restricted execution. Hard: Fix marshal (and perhaps new) by adding checks on code objects before returning them. Probably no way to do this exhaustively. Lateral thinking: prohibit exec in restricted mode? (Currently eval() also allows execution of code objects, so that would have to be changed too.) I think this is a nice complement to the existing features of restricted execution mode, which prevent the attachment of a new code object to a function. On the other hand, there's not much point fixing this unless other methods of crashing the interpreter are also hunted down... >>> class C: ... def __cmp__(self, other): ... pop(0) ... return 1 ... >>> gl = [C() for i in '1'*20] >>> pop=gl.pop >>> gl.sort() Segmentation fault (core dumped) (should I submit this as a separate bug report?) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-11-12 15:34 Message: Logged In: YES user_id=4771 The list.sort() problem could be quickly solved by stealing the ob_item array away from the list object itself at the beginning of the sort. The list object would appear to be empty during the sort. The ob_item array would be put back into place at the end, with a check that the list is still empty. A possible drawback is that len() of a list being sorted is 0, althought one might argue that this should return the correct length. The immutable list trick could be removed -- or kept around for the error messages it provides, althought I'd vote against it: Python and Python programmers generally assume that the type is an immutable property of an object. See patch http://www.python.org/sf/637176 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-03 22:35 Message: Logged In: YES user_id=31435 Assuming "this front" means the list.sort() crasher, not unless Guido raises the priority from 1 to, oh, at least 8 . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-03 18:27 Message: Logged In: YES user_id=6656 Is there any realistic chance of anything happening on this front in the 2.2.1 timeframe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 23:04 Message: Logged In: YES user_id=6380 Sigh. I wished I'd picked this up earlier, but I haven't. After 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 18:43 Message: Logged In: YES user_id=6380 I'm not so interested in the list.sort crasher, so I'm lowering the priority and unassigning it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-30 14:51 Message: Logged In: YES user_id=6656 OK, done, in: marshal.c version 1.67 Changed summary. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 12:48 Message: Logged In: YES user_id=6380 Michael's patch is fine -- the code-loading is not done in restricted mode (but the execution is, because the restricted globals are passed). Michael, can you check it in? The list issue could be fixed by adding a PyList_Check() call to each list method implementation (or at least to the mutating ones). But is it sufficient? I believe there are plenty of other ways to cause a crash -- stack overflow is one, and I think marshal itself can also crash on corrupt input. Greg's bug report points out that rexec is far from sufficient to deter a real hacker. Imagine that this was used in a popular email program... :-( If we can't deprecate rexec, perhaps we should add very big warnings to the documentation that it can't be trusted against truly hostile users. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-30 06:45 Message: Logged In: YES user_id=31435 Reassigning to Guido. The patch stops marshal from loading a code object when in restricted mode, but I have no feel for whether that's going to be a serious limitation for restricted mode (which I've never used for real). For example, wouldn't this also stop regular old imports from .pyc files? I'd hate for restricted users to be barred from importing tabnanny . The list-crasher is a different issue, but I went over *my* limit for caring about trying to foil hostile users when we added the immutable list type. That trick doesn't help here (the mutating mutable-list method is captured in a bound method object before the sort is invoked). I suppose we could instead check that the list base address and length haven't changed after every compare -- but with N*log(N) compares, that's a significant expense the immutable list trick was trying to get away from. Not worth it to me, but my native interest in competing with hostile users is admittedly undetectable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-25 07:25 Message: Logged In: YES user_id=6656 I think a reasonable approach to the first problem is to not let marshal load code objects when in restricted execution mode. The second crasher you mention is much more worrying, to me. I think it blows the "immutable list trick" out of the water. I'll attach a patch to marshal (from another machine) and assign to Tim to think about the list nagery. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:45:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:45:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-494203 ] Interpreter won't always exit with daemonic thread Message-ID: Bugs item #494203, was opened at 2001-12-17 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 Category: Threads Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Morten W. Petersen (morphex) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter won't always exit with daemonic thread Initial Comment: See file. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 15:45 Message: Logged In: YES user_id=7887 I couldn't reproduce it on Conectiva Linux 8.0 as well. Looking trough the trace, I found out that there's some realtime management going on. Then, I tried to preload librt.so, and that made my trace look pretty similar to the attached one. Even then, I wasn't able to reproduce the problem. Morten, can you still reproduce this bug in Python 2.2.2? If so, I'll look for an environment similar to yours. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 17:06 Message: Logged In: YES user_id=6380 gdb? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 16:57 Message: Logged In: YES user_id=68005 I can't interpret it either. :-) Is there another way to to provide debugging information ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 16:48 Message: Logged In: YES user_id=6380 Sorry, I don't know how to interpret the trace. Someone else, please? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 16:42 Message: Logged In: YES user_id=68005 I'm attaching a trace.. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 16:33 Message: Logged In: YES user_id=6380 I dunno. They're likely to shoot back to Python. Can you do some more digging (e.g. what is the program doing when it's hanging)? ---------------------------------------------------------------------- Comment By: Morten W. Petersen (morphex) Date: 2001-12-17 16:21 Message: Logged In: YES user_id=68005 Ok, the system I'm using is: morten@debian$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> morten@debian$ uname -a Linux debian 2.4.14 #1 SMP Mon Dec 10 20:40:22 CET 2001 i686 unknown With a customized kernel. Should I contact the Debian maintainers ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 15:58 Message: Logged In: YES user_id=6380 I can't reproduce this on Red Hat 6.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=494203&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:53:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:53:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 16:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:58:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:58:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-636685 ] ftplib bails out on empty responses Message-ID: Bugs item #636685, was opened at 2002-11-11 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib bails out on empty responses Initial Comment: In ftplib.py, FTP.getresp(), there is: if c in '123', and c is the first char of the reponse line. However, if the response is empty, then this line will throw an exception: File "/usr/lib/python2.2/ftplib.py", line 108, in __init__ self.connect(host) File "/usr/lib/python2.2/ftplib.py", line 133, in connect self.welcome = self.getresp() File "/usr/lib/python2.2/ftplib.py", line 216, in getresp if c not in '123': TypeError: 'in ' requires character as left operand System info: LinkChecker 1.6.6 Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 I suggest you test if c is a character before calling the if-clause. Cheers, Bastian ---------------------------------------------------------------------- >Comment By: Bastian Kleineidam (calvin) Date: 2002-11-12 16:58 Message: Logged In: YES user_id=9205 I dont know which FTP server causes the exception, I already asked the submitter to provide more info. You can find the assorted bug report for this at http://sourceforge.net/tracker/index.php?func=detail&aid=635596&group_id=1913&atid=101913 Anyway, the ftplib code makes a non-guaranteed assumption about the response length. I think a solution would be to throw an ftplib error in case of an empty response. Cheers, Bastian ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:22 Message: Logged In: YES user_id=21627 Can you please explain in what case the server is supposed to send an empty response? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 From noreply@sourceforge.net Tue Nov 12 15:58:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 07:58:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius Gedminas (mgedmin) Assigned to: Gustavo Niemeyer (niemeyer) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=7887 Great catch Marius! Thank you very much! I could identify the following problems from your report: - If (requestsize == -1) and after a few iterations, fread() signals EWOULDBLOCK with (chunksize == 0), all read data is lost because an exception is raised. - When (chunksize != 0) and EWOULDBLOCK is signaled, ferror() will be flagged. Then the next iteration will fail if: 1) read data has length 0 because EWOULDBLOCK is signaled again but errno is still set to 0 (I don't know why errno is not reset in that case); 2) read data has length 0 because a block with the exact requested size is read. The attached tests show these problems. The first problem is a little bit harder to trigger. I had to preset SMALLCHUNK to 4096 in fileobject.c, because my Linux refused to return a chunk greater than that from fread(). The second problem should be visible without further tweakings. I have also attached a solution to the problem. This solution works because: - If (chunksize == 0), (errno == EWOULDBLOCK) and (readbytes > 0), there's no point in raising an exception, as we got some data for the user, just like when (bytesread < buffersize). - When (chunksize != 0) and EWOULDBLOCK is signaled, it's not considered an error. OTOH, ferror() is still being set. clearerr() should be called in the stream before breaking the loop. - If (bytesread == buffersize) and (bytesrequest >= 0), it means that we already got all the requested data, and thus there's no point in trying to read more data from the file and forcing (chunksize == 0) without ferror() being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Tue Nov 12 16:34:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 08:34:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 16:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 15:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 14:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 16:36:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 08:36:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-636685 ] ftplib bails out on empty responses Message-ID: Bugs item #636685, was opened at 2002-11-11 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib bails out on empty responses Initial Comment: In ftplib.py, FTP.getresp(), there is: if c in '123', and c is the first char of the reponse line. However, if the response is empty, then this line will throw an exception: File "/usr/lib/python2.2/ftplib.py", line 108, in __init__ self.connect(host) File "/usr/lib/python2.2/ftplib.py", line 133, in connect self.welcome = self.getresp() File "/usr/lib/python2.2/ftplib.py", line 216, in getresp if c not in '123': TypeError: 'in ' requires character as left operand System info: LinkChecker 1.6.6 Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 I suggest you test if c is a character before calling the if-clause. Cheers, Bastian ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 17:36 Message: Logged In: YES user_id=21627 I believe the assumption is guaranteed by the FTP protocol. I think we really need more information here. If you can come up with a tested patch (i.e. tested by your user, for this respective server), this might be sufficient to make a change - but I won't make a change without having understood all details of the change. If this is what it looks like (i.e. a protocol violation), error_proto would be appropriate. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-11-12 16:58 Message: Logged In: YES user_id=9205 I dont know which FTP server causes the exception, I already asked the submitter to provide more info. You can find the assorted bug report for this at http://sourceforge.net/tracker/index.php?func=detail&aid=635596&group_id=1913&atid=101913 Anyway, the ftplib code makes a non-guaranteed assumption about the response length. I think a solution would be to throw an ftplib error in case of an empty response. Cheers, Bastian ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:22 Message: Logged In: YES user_id=21627 Can you please explain in what case the server is supposed to send an empty response? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 From noreply@sourceforge.net Tue Nov 12 16:38:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 08:38:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 17:38 Message: Logged In: YES user_id=21627 So your class does have an __str__? Or is it the __repr__ that is being used? ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 16:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 16:40:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 08:40:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-637217 ] inspect.getargspec: None instead of () Message-ID: Bugs item #637217, was opened at 2002-11-12 16:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637217&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nathan Srebro (nati) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec: None instead of () Initial Comment: When a function has no default arguments, getargspec (in module inspec) returns a fourth return-value of None: >>> inspect.getargspec(lambda x:x) (['x'], None, None, None) According to the documentation, the fourth return value, defaults, "is a tuple of default argument values; if this tuple has n elements, they correspond to the last n elements listed in args.". This suggests that if there are no default arguments, an empty tuple should be returned. This is also more consistent. Returning None requires special handling in code using this return value. Attached is a corrected version of getargspec (a check for 'defaults is None' is added). (This bug exists in both 2.2.2 and the current CVS) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637217&group_id=5470 From noreply@sourceforge.net Tue Nov 12 16:43:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 08:43:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius Gedminas (mgedmin) >Assigned to: Martin v. Löwis (loewis) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 16:43 Message: Logged In: YES user_id=7887 Martin, could you please review that? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=7887 Great catch Marius! Thank you very much! I could identify the following problems from your report: - If (requestsize == -1) and after a few iterations, fread() signals EWOULDBLOCK with (chunksize == 0), all read data is lost because an exception is raised. - When (chunksize != 0) and EWOULDBLOCK is signaled, ferror() will be flagged. Then the next iteration will fail if: 1) read data has length 0 because EWOULDBLOCK is signaled again but errno is still set to 0 (I don't know why errno is not reset in that case); 2) read data has length 0 because a block with the exact requested size is read. The attached tests show these problems. The first problem is a little bit harder to trigger. I had to preset SMALLCHUNK to 4096 in fileobject.c, because my Linux refused to return a chunk greater than that from fread(). The second problem should be visible without further tweakings. I have also attached a solution to the problem. This solution works because: - If (chunksize == 0), (errno == EWOULDBLOCK) and (readbytes > 0), there's no point in raising an exception, as we got some data for the user, just like when (bytesread < buffersize). - When (chunksize != 0) and EWOULDBLOCK is signaled, it's not considered an error. OTOH, ferror() is still being set. clearerr() should be called in the stream before breaking the loop. - If (bytesread == buffersize) and (bytesrequest >= 0), it means that we already got all the requested data, and thus there's no point in trying to read more data from the file and forcing (chunksize == 0) without ferror() being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Tue Nov 12 16:45:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 08:45:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 16:45 Message: Logged In: YES user_id=612691 Usually it does not have __str__, so __repr__ is getting used. In other cases, the class does have a __str__, and it gets used, but even then I think it shouldn't if there's a __unicode__ All this presumes there's a way to diagnose whether files are wide or narrow -- I'm not familiar enough with the implementation details here to know if this makes sense or not. My original message made the point as follows: If you call str(object), and object's class has a __str__ method, the value is the value of the __str__ method; If you print an object to a normal stream, and object's class has a __str__ method, what appears is the result of the __str__ method. If you call unicode(object), and object's class has a __unicode__ method, the value is the value of the __unicode__ method; So far so good, but read on . . . If you print an object to a unicode stream, and object's class has a __unicode__ method, what appears is the result of . . . _not_ the __unicode__ method, but the __str__ method, if there is one, otherwise the usual default ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:38 Message: Logged In: YES user_id=21627 So your class does have an __str__? Or is it the __repr__ that is being used? ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 16:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 15:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 14:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply@sourceforge.net Tue Nov 12 19:33:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:33:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-637320 ] socket fails when profiling Message-ID: Bugs item #637320, was opened at 2002-11-12 20:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637320&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: socket fails when profiling Initial Comment: Profiling a script, that (directly or indirectly) imports socket fails (on Linux): > cat test.py import socket > /usr/local/lib/python2.3/profile.py test.py Traceback (most recent call last): File "/usr/local/lib/python2.3/profile.py", line 555, in ? run('execfile(' + `filename` + ')') File "/usr/local/lib/python2.3/profile.py", line 71, in run prof = prof.run(statement) File "/usr/local/lib/python2.3/profile.py", line 403, in run return self.runctx(cmd, dict, dict) File "/usr/local/lib/python2.3/profile.py", line 409, in runctx exec cmd in globals, locals File "", line 1, in ? File "test.py", line 1, in ? import socket File "/usr/local/lib/python2.3/socket.py", line 144, in ? class _socketobject(object): File "/usr/local/lib/python2.3/socket.py", line 180, in _socketobject exec _s % (_m, _m, _m, _m) File "", line 3, in ? AttributeError: type object '_socket.socket' has no attribute 'settimeout' Removing 'settimeout' and 'gettimeout' from _socketmethods fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637320&group_id=5470 From noreply@sourceforge.net Tue Nov 12 19:34:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:34:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-637321 ] _POSIX_C_SOURCE redfined Message-ID: Bugs item #637321, was opened at 2002-11-12 19:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: _POSIX_C_SOURCE redfined Initial Comment: I recently build and installed a current CVS python. When I used it to build some C extension modules, I get a warning about redefinition of _POSIX_C_SOURCE. Is this related to your recent changes? building 'ExtensionClass' extension gcc -g -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.3 -c ExtensionClass/src/ExtensionClass.c -o build/temp.linux-i686-2.3/ExtensionClass.o In file included from /usr/local/include/python2.3/Python.h:8, from ExtensionClass/src/ExtensionClass.h:94, from ExtensionClass/src/ExtensionClass.c:28: /usr/local/include/python2.3/pyconfig.h:795: warning: `_POSIX_C_SOURCE' redefined /usr/include/features.h:164: warning: this is the location of the previous definition ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 From noreply@sourceforge.net Tue Nov 12 19:38:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:38:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-637320 ] socket fails when profiling Message-ID: Bugs item #637320, was opened at 2002-11-12 20:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637320&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Deleted >Resolution: Invalid Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: socket fails when profiling Initial Comment: Profiling a script, that (directly or indirectly) imports socket fails (on Linux): > cat test.py import socket > /usr/local/lib/python2.3/profile.py test.py Traceback (most recent call last): File "/usr/local/lib/python2.3/profile.py", line 555, in ? run('execfile(' + `filename` + ')') File "/usr/local/lib/python2.3/profile.py", line 71, in run prof = prof.run(statement) File "/usr/local/lib/python2.3/profile.py", line 403, in run return self.runctx(cmd, dict, dict) File "/usr/local/lib/python2.3/profile.py", line 409, in runctx exec cmd in globals, locals File "", line 1, in ? File "test.py", line 1, in ? import socket File "/usr/local/lib/python2.3/socket.py", line 144, in ? class _socketobject(object): File "/usr/local/lib/python2.3/socket.py", line 180, in _socketobject exec _s % (_m, _m, _m, _m) File "", line 3, in ? AttributeError: type object '_socket.socket' has no attribute 'settimeout' Removing 'settimeout' and 'gettimeout' from _socketmethods fixes the problem. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-11-12 20:38 Message: Logged In: YES user_id=89016 Ouch, this was a mixup of Python versions. Closing the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637320&group_id=5470 From noreply@sourceforge.net Tue Nov 12 19:54:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:54:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-637321 ] _POSIX_C_SOURCE redfined Message-ID: Bugs item #637321, was opened at 2002-11-12 20:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: _POSIX_C_SOURCE redfined Initial Comment: I recently build and installed a current CVS python. When I used it to build some C extension modules, I get a warning about redefinition of _POSIX_C_SOURCE. Is this related to your recent changes? building 'ExtensionClass' extension gcc -g -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.3 -c ExtensionClass/src/ExtensionClass.c -o build/temp.linux-i686-2.3/ExtensionClass.o In file included from /usr/local/include/python2.3/Python.h:8, from ExtensionClass/src/ExtensionClass.h:94, from ExtensionClass/src/ExtensionClass.c:28: /usr/local/include/python2.3/pyconfig.h:795: warning: `_POSIX_C_SOURCE' redefined /usr/include/features.h:164: warning: this is the location of the previous definition ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 20:54 Message: Logged In: YES user_id=21627 Unlikely. More likely, ExtensionClass.c includes a system header before including Python.h, which is an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 From noreply@sourceforge.net Tue Nov 12 19:59:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 11:59:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-637321 ] _POSIX_C_SOURCE redfined Message-ID: Bugs item #637321, was opened at 2002-11-12 19:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: _POSIX_C_SOURCE redfined Initial Comment: I recently build and installed a current CVS python. When I used it to build some C extension modules, I get a warning about redefinition of _POSIX_C_SOURCE. Is this related to your recent changes? building 'ExtensionClass' extension gcc -g -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.3 -c ExtensionClass/src/ExtensionClass.c -o build/temp.linux-i686-2.3/ExtensionClass.o In file included from /usr/local/include/python2.3/Python.h:8, from ExtensionClass/src/ExtensionClass.h:94, from ExtensionClass/src/ExtensionClass.c:28: /usr/local/include/python2.3/pyconfig.h:795: warning: `_POSIX_C_SOURCE' redefined /usr/include/features.h:164: warning: this is the location of the previous definition ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-11-12 19:59 Message: Logged In: YES user_id=31392 It looks like stdio.h is included first (and redundantly) in ExtensionClass.c. I've never seen the warning before, so some recent change to python has exposed the problem in ExtensionClass. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 19:54 Message: Logged In: YES user_id=21627 Unlikely. More likely, ExtensionClass.c includes a system header before including Python.h, which is an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 From noreply@sourceforge.net Tue Nov 12 20:14:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 12:14:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-637321 ] _POSIX_C_SOURCE redfined Message-ID: Bugs item #637321, was opened at 2002-11-12 20:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 Category: Build Group: None Status: Closed Resolution: Later Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: _POSIX_C_SOURCE redfined Initial Comment: I recently build and installed a current CVS python. When I used it to build some C extension modules, I get a warning about redefinition of _POSIX_C_SOURCE. Is this related to your recent changes? building 'ExtensionClass' extension gcc -g -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.3 -c ExtensionClass/src/ExtensionClass.c -o build/temp.linux-i686-2.3/ExtensionClass.o In file included from /usr/local/include/python2.3/Python.h:8, from ExtensionClass/src/ExtensionClass.h:94, from ExtensionClass/src/ExtensionClass.c:28: /usr/local/include/python2.3/pyconfig.h:795: warning: `_POSIX_C_SOURCE' redefined /usr/include/features.h:164: warning: this is the location of the previous definition ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 21:14 Message: Logged In: YES user_id=21627 Ah, right. I changed _POSIX_C_SOURCE to 200112L, which, I believe, is the value corresponding to _XOPEN_SOURCE 600. There was always a duplicate definition, but that gives only a warning if the new definition is different from the old one. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-11-12 20:59 Message: Logged In: YES user_id=31392 It looks like stdio.h is included first (and redundantly) in ExtensionClass.c. I've never seen the warning before, so some recent change to python has exposed the problem in ExtensionClass. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 20:54 Message: Logged In: YES user_id=21627 Unlikely. More likely, ExtensionClass.c includes a system header before including Python.h, which is an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637321&group_id=5470 From noreply@sourceforge.net Tue Nov 12 21:46:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 13:46:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher Message-ID: Bugs item #453523, was opened at 2001-08-20 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 1 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Tim Peters (tim_one) Summary: list.sort crasher Initial Comment: The marshal module is on the default list of ok builtin modules, but it can be used to crash the interpreter. The new module, on the other hand, is not allowed. To me the only obvious reason for this is that it provides a way to make new code objects, which can then crash the interpreter. But marshal also gives this ability. Example is attached as a file. Having imported marshal, I use marshal.loads() on a carefully constructed string to get a corrupt code object. To work out this string: (in unrestricted mode) def f(): pass import marshal badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N', '(\x00\x00\x00\x00') which when loaded gives a code object with co_consts = (). Possible fixes: Easy: remove marshal from the list of approved modules for restricted execution. Hard: Fix marshal (and perhaps new) by adding checks on code objects before returning them. Probably no way to do this exhaustively. Lateral thinking: prohibit exec in restricted mode? (Currently eval() also allows execution of code objects, so that would have to be changed too.) I think this is a nice complement to the existing features of restricted execution mode, which prevent the attachment of a new code object to a function. On the other hand, there's not much point fixing this unless other methods of crashing the interpreter are also hunted down... >>> class C: ... def __cmp__(self, other): ... pop(0) ... return 1 ... >>> gl = [C() for i in '1'*20] >>> pop=gl.pop >>> gl.sort() Segmentation fault (core dumped) (should I submit this as a separate bug report?) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-12 16:46 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-11-12 10:34 Message: Logged In: YES user_id=4771 The list.sort() problem could be quickly solved by stealing the ob_item array away from the list object itself at the beginning of the sort. The list object would appear to be empty during the sort. The ob_item array would be put back into place at the end, with a check that the list is still empty. A possible drawback is that len() of a list being sorted is 0, althought one might argue that this should return the correct length. The immutable list trick could be removed -- or kept around for the error messages it provides, althought I'd vote against it: Python and Python programmers generally assume that the type is an immutable property of an object. See patch http://www.python.org/sf/637176 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-03 17:35 Message: Logged In: YES user_id=31435 Assuming "this front" means the list.sort() crasher, not unless Guido raises the priority from 1 to, oh, at least 8 . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-03 13:27 Message: Logged In: YES user_id=6656 Is there any realistic chance of anything happening on this front in the 2.2.1 timeframe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 18:04 Message: Logged In: YES user_id=6380 Sigh. I wished I'd picked this up earlier, but I haven't. After 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 14:43 Message: Logged In: YES user_id=6380 I'm not so interested in the list.sort crasher, so I'm lowering the priority and unassigning it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-30 10:51 Message: Logged In: YES user_id=6656 OK, done, in: marshal.c version 1.67 Changed summary. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 08:48 Message: Logged In: YES user_id=6380 Michael's patch is fine -- the code-loading is not done in restricted mode (but the execution is, because the restricted globals are passed). Michael, can you check it in? The list issue could be fixed by adding a PyList_Check() call to each list method implementation (or at least to the mutating ones). But is it sufficient? I believe there are plenty of other ways to cause a crash -- stack overflow is one, and I think marshal itself can also crash on corrupt input. Greg's bug report points out that rexec is far from sufficient to deter a real hacker. Imagine that this was used in a popular email program... :-( If we can't deprecate rexec, perhaps we should add very big warnings to the documentation that it can't be trusted against truly hostile users. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-30 02:45 Message: Logged In: YES user_id=31435 Reassigning to Guido. The patch stops marshal from loading a code object when in restricted mode, but I have no feel for whether that's going to be a serious limitation for restricted mode (which I've never used for real). For example, wouldn't this also stop regular old imports from .pyc files? I'd hate for restricted users to be barred from importing tabnanny . The list-crasher is a different issue, but I went over *my* limit for caring about trying to foil hostile users when we added the immutable list type. That trick doesn't help here (the mutating mutable-list method is captured in a bound method object before the sort is invoked). I suppose we could instead check that the list base address and length haven't changed after every compare -- but with N*log(N) compares, that's a significant expense the immutable list trick was trying to get away from. Not worth it to me, but my native interest in competing with hostile users is admittedly undetectable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-25 03:25 Message: Logged In: YES user_id=6656 I think a reasonable approach to the first problem is to not let marshal load code objects when in restricted execution mode. The second crasher you mention is much more worrying, to me. I think it blows the "immutable list trick" out of the water. I'll attach a patch to marshal (from another machine) and assign to Tim to think about the list nagery. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 From noreply@sourceforge.net Tue Nov 12 21:58:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 13:58:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 13:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 02:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 01:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 14:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 13:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 23:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 11:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 21:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Tue Nov 12 22:17:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 14:17:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher Message-ID: Bugs item #453523, was opened at 2001-08-20 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Tim Peters (tim_one) Summary: list.sort crasher Initial Comment: The marshal module is on the default list of ok builtin modules, but it can be used to crash the interpreter. The new module, on the other hand, is not allowed. To me the only obvious reason for this is that it provides a way to make new code objects, which can then crash the interpreter. But marshal also gives this ability. Example is attached as a file. Having imported marshal, I use marshal.loads() on a carefully constructed string to get a corrupt code object. To work out this string: (in unrestricted mode) def f(): pass import marshal badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N', '(\x00\x00\x00\x00') which when loaded gives a code object with co_consts = (). Possible fixes: Easy: remove marshal from the list of approved modules for restricted execution. Hard: Fix marshal (and perhaps new) by adding checks on code objects before returning them. Probably no way to do this exhaustively. Lateral thinking: prohibit exec in restricted mode? (Currently eval() also allows execution of code objects, so that would have to be changed too.) I think this is a nice complement to the existing features of restricted execution mode, which prevent the attachment of a new code object to a function. On the other hand, there's not much point fixing this unless other methods of crashing the interpreter are also hunted down... >>> class C: ... def __cmp__(self, other): ... pop(0) ... return 1 ... >>> gl = [C() for i in '1'*20] >>> pop=gl.pop >>> gl.sort() Segmentation fault (core dumped) (should I submit this as a separate bug report?) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-12 17:17 Message: Logged In: YES user_id=31435 Armin's patch has been applied for 2.3, so closing this as fixed. Whether it's a bugfix candidate is debatable, since it can also change behavior of "working" code. I changed the docs too so that it can longer be considered working code . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-12 16:46 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-11-12 10:34 Message: Logged In: YES user_id=4771 The list.sort() problem could be quickly solved by stealing the ob_item array away from the list object itself at the beginning of the sort. The list object would appear to be empty during the sort. The ob_item array would be put back into place at the end, with a check that the list is still empty. A possible drawback is that len() of a list being sorted is 0, althought one might argue that this should return the correct length. The immutable list trick could be removed -- or kept around for the error messages it provides, althought I'd vote against it: Python and Python programmers generally assume that the type is an immutable property of an object. See patch http://www.python.org/sf/637176 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-03 17:35 Message: Logged In: YES user_id=31435 Assuming "this front" means the list.sort() crasher, not unless Guido raises the priority from 1 to, oh, at least 8 . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-03 13:27 Message: Logged In: YES user_id=6656 Is there any realistic chance of anything happening on this front in the 2.2.1 timeframe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-11 18:04 Message: Logged In: YES user_id=6380 Sigh. I wished I'd picked this up earlier, but I haven't. After 2.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-04 14:43 Message: Logged In: YES user_id=6380 I'm not so interested in the list.sort crasher, so I'm lowering the priority and unassigning it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-30 10:51 Message: Logged In: YES user_id=6656 OK, done, in: marshal.c version 1.67 Changed summary. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-30 08:48 Message: Logged In: YES user_id=6380 Michael's patch is fine -- the code-loading is not done in restricted mode (but the execution is, because the restricted globals are passed). Michael, can you check it in? The list issue could be fixed by adding a PyList_Check() call to each list method implementation (or at least to the mutating ones). But is it sufficient? I believe there are plenty of other ways to cause a crash -- stack overflow is one, and I think marshal itself can also crash on corrupt input. Greg's bug report points out that rexec is far from sufficient to deter a real hacker. Imagine that this was used in a popular email program... :-( If we can't deprecate rexec, perhaps we should add very big warnings to the documentation that it can't be trusted against truly hostile users. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-30 02:45 Message: Logged In: YES user_id=31435 Reassigning to Guido. The patch stops marshal from loading a code object when in restricted mode, but I have no feel for whether that's going to be a serious limitation for restricted mode (which I've never used for real). For example, wouldn't this also stop regular old imports from .pyc files? I'd hate for restricted users to be barred from importing tabnanny . The list-crasher is a different issue, but I went over *my* limit for caring about trying to foil hostile users when we added the immutable list type. That trick doesn't help here (the mutating mutable-list method is captured in a bound method object before the sort is invoked). I suppose we could instead check that the list base address and length haven't changed after every compare -- but with N*log(N) compares, that's a significant expense the immutable list trick was trying to get away from. Not worth it to me, but my native interest in competing with hostile users is admittedly undetectable. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-08-25 03:25 Message: Logged In: YES user_id=6656 I think a reasonable approach to the first problem is to not let marshal load code objects when in restricted execution mode. The second crasher you mention is much more worrying, to me. I think it blows the "immutable list trick" out of the water. I'll attach a patch to marshal (from another machine) and assign to Tim to think about the list nagery. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470 From noreply@sourceforge.net Tue Nov 12 23:01:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 15:01:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Neal Norwitz (nnorwitz) >Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:01 Message: Logged In: YES user_id=33168 In order to deal with either the format or the arg being a string or unicode, I changed the code to check PyObject_TypeCheck(args, &PyBaseString_Type). This was changed in both PyString_Format and PyUnicode_Format. Checked in as: * Objects/unicodeobject.c 2.174 * Objects/stringobject.c 2.196 * Lib/test/test_format.py 1.18 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-11 05:29 Message: Logged In: YES user_id=6656 You're right. Please do add a test! Also note that unicode's are mappings too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 11:35 Message: Logged In: YES user_id=33168 The problem is that string is a mapping (also changed in 2.166). The patch below fixes the problem. Michael, do you have any problem with this change? If not, I'll check it in with a test (unless you beat me to it). - if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args) && !PyString_Check(args)) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:49 Message: Logged In: YES user_id=33168 Let me try that again: r'.po$' % ("hallo",) The line was changed in rev 2.166 by mwh for extended slicing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 10:45 Message: Logged In: YES user_id=33168 I'm pretty sure this change (between 2.2.2 and 2.3) in stringobject.c is the problem: @@ -3320,7 +3623,7 @@ arglen = -1; argidx = -2; } - if (args->ob_type->tp_as_mapping) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) dict = args; Now for non-tuples, dict is set. dict is used later on to determine if an exception should be set. This still works, ie produces the exception: (r'.po$' % "hallo",) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Tue Nov 12 23:14:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 15:14:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-635595 ] Misleading description of \w in regexs Message-ID: Bugs item #635595, was opened at 2002-11-08 12:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635595&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Misleading description of \w in regexs Initial Comment: In the Regular Expression Syntax doc page (http://www.python.org/dev/doc/devel/lib/re-syntax.html), the description for \w is misleading (the same goes for \W). The description indicates that, with the locale flag in effect, \w includes "characters defined as letters" for the current locale. In reading that, I took "letters" to mean characters for which isalpha returns true, but, in fact, all characters defined as alphanumerics for the current locale are included (so \w works pretty much the same way with locale flag as with the unicode flag). For example (using '\xb2', the superscript two): Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'English_United States.1252' >>> import re >>> re.match(r'\w', '\xb2', re.L).group() '\xb2' ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-12 18:14 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libre.tex revisions 1.91 and 1.73.6.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635595&group_id=5470 From noreply@sourceforge.net Tue Nov 12 23:16:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 15:16:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field Message-ID: Bugs item #626570, was opened at 2002-10-21 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Michael S. Fischer (otterley) >Assigned to: Neal Norwitz (nnorwitz) Summary: strptime() always returns 0 in dst field Initial Comment: time.strptime() has always returned 0 in the Daylight Savings Time flag of the returned tuple. This leads to nasty bugs like the "off by an hour" bug revealed below: >>> strftime("%Y %b %d %H %M %S %Z", localtime(int(mktime(strptime("Oct 18 2002 00:00:00", "%b %d %Y %H:%M:%S"))))) '2002 Oct 18 01 00 00 PDT' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:16 Message: Logged In: YES user_id=33168 Michael, I'm closing this as "Won't Fix." I agree there is a problem in 2.2.x, but I don't believe this is possible to fix without creating backwards compatibility problems. As I mentioned earlier, this is fixed in 2.3. If you would like to discuss this further, please send mail to python-dev@python.org. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-11-02 15:03 Message: Logged In: YES user_id=357491 I think Neal is right in thinking that changing this might break backwards compatibility. If someone stored timestamps as the tuples directly and then suddenly the new timestamps for something started having a different dst value all the calculations comparing new and old will be off if they use the dst flag. This tends to be a bad thing when changing between dot releases. Besides, if the DST flag is that important it should have been specified in the string passed to strptime(). Otherwise strptime has to just assume there is none (like in 2.2), or guess (like in 2.3). You are basically paying the price for wanting strptime() to infer what you want dst to be. The docs also say that you are at the mercy of the underlying C library and there is a lot of variety for strptime() since it is not a part of ANSI C. In other words, I say this is all a moot point. If accurate timing is that important use UTC timestamps. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-22 18:42 Message: Logged In: YES user_id=33168 I'll have to look at this more. With 2.3, I get 00 00 00, with 1.5.2, 2.1.1, and 2.2.2, I get 01 00 00. The difference seems to be that the tm_isdst flag is set to -1 (mktime should guess) in 2.3, but the flag is set to 0 in other versions. It's possible this bug may not be able to be fixed due to backwards compatibility. ---------------------------------------------------------------------- Comment By: Michael S. Fischer (otterley) Date: 2002-10-21 19:43 Message: Logged In: YES user_id=7820 I've seen it in 1.5.2, 2.1.3, 2.2 and 2.2.1. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-21 19:34 Message: Logged In: YES user_id=33168 Michael, what version(s) of Python does this effect? 2.2.2? 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 From noreply@sourceforge.net Tue Nov 12 23:21:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 15:21:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Wed Nov 13 03:33:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 19:33:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) >Assigned to: Martin v. Löwis (loewis) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 22:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 05:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 04:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 04:00:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Nov 2002 20:00:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-637547 ] "u#" doesn't check object type Message-ID: Bugs item #637547, was opened at 2002-11-13 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637547&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: M.-A. Lemburg (lemburg) Summary: "u#" doesn't check object type Initial Comment: PyArg_ParseTuple(arg, "u#", p) doesn't check type of argument. So passing string object, PyArg_ParseTuple() doesn't report error and returns broken Unicode string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637547&group_id=5470 From noreply@sourceforge.net Wed Nov 13 08:34:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 00:34:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) >Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 09:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 04:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 11:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 10:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 09:01:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 01:01:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Eddy De Greef (edg) Date: 2002-11-13 10:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 09:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 04:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 11:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 10:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 10:55:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 02:55:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-635969 ] No error "not all arguments converted" Message-ID: Bugs item #635969, was opened at 2002-11-09 17:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Neal Norwitz (nnorwitz) >Summary: No error "not all arguments converted" Initial Comment: The expression r'.po$' % "hallo" used to give an error, but now succeeds and gives the string '.po'. I think producing the error should be restored. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-13 10:55 Message: Logged In: YES user_id=6656 Of course, the moral to this story is "always pass a tuple to str % args"... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 23:01 Message: Logged In: YES user_id=33168 In order to deal with either the format or the arg being a string or unicode, I changed the code to check PyObject_TypeCheck(args, &PyBaseString_Type). This was changed in both PyString_Format and PyUnicode_Format. Checked in as: * Objects/unicodeobject.c 2.174 * Objects/stringobject.c 2.196 * Lib/test/test_format.py 1.18 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-11 10:29 Message: Logged In: YES user_id=6656 You're right. Please do add a test! Also note that unicode's are mappings too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 16:35 Message: Logged In: YES user_id=33168 The problem is that string is a mapping (also changed in 2.166). The patch below fixes the problem. Michael, do you have any problem with this change? If not, I'll check it in with a test (unless you beat me to it). - if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args) && !PyString_Check(args)) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 15:49 Message: Logged In: YES user_id=33168 Let me try that again: r'.po$' % ("hallo",) The line was changed in rev 2.166 by mwh for extended slicing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-10 15:45 Message: Logged In: YES user_id=33168 I'm pretty sure this change (between 2.2.2 and 2.3) in stringobject.c is the problem: @@ -3320,7 +3623,7 @@ arglen = -1; argidx = -2; } - if (args->ob_type->tp_as_mapping) + if (args->ob_type->tp_as_mapping && !PyTuple_Check(args)) dict = args; Now for non-tuples, dict is set. dict is used later on to determine if an exception should be set. This still works, ie produces the exception: (r'.po$' % "hallo",) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635969&group_id=5470 From noreply@sourceforge.net Wed Nov 13 12:04:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 04:04:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 22:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Wed Nov 13 14:35:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 06:35:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-637789 ] httplib doesn't know proxy-connection Message-ID: Bugs item #637789, was opened at 2002-11-13 22:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637789&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Chih-Chung Chang (jochang) Assigned to: Nobody/Anonymous (nobody) Summary: httplib doesn't know proxy-connection Initial Comment: HTTPResponse uses the 'connection' header to determine keep-alive or not, but when talking to a proxy server, the 'proxy-connection' header might be used instead. After checking for the 'connection' header, we should also check the 'proxy-connection' header like this: conn = self.msg.getheader('Proxy-Connection') if conn.find('keep-alive') != -1: self.will_close = False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637789&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:00:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:00:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 23:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-20 22:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 17:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 17:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:03:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:03:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-637807 ] Minuscule typo in lib docs 4.2.5 Message-ID: Bugs item #637807, was opened at 2002-11-13 15:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637807&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Minuscule typo in lib docs 4.2.5 Initial Comment: In section 4.2.5 ("Match Objects"), the "start" and "end" methods are described as "start([group])" and "end([group])". In both cases, "group" is (corectly) in italics, but in the case of "end", the square brackets surrounding "group" are also italicized. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637807&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:11:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:11:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-637810 ] "it's" used instead of "its" Message-ID: Bugs item #637810, was opened at 2002-11-13 15:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: "it's" used instead of "its" Initial Comment: I have found two places in the documentation where "it's" appears in a context where "its" is correct: section 13.6.2.3 (it's list of child nodes), 4.2.1 (by it's ordinal value). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:40:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:40:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 16:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 01:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-21 00:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 19:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 19:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:48:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:48:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-637810 ] "it's" used instead of "its" Message-ID: Bugs item #637810, was opened at 2002-11-13 10:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Pending Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: "it's" used instead of "its" Initial Comment: I have found two places in the documentation where "it's" appears in a context where "its" is correct: section 13.6.2.3 (it's list of child nodes), 4.2.1 (by it's ordinal value). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 10:48 Message: Logged In: YES user_id=3066 Andrew: Section 4.2.1 of which document? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:50:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:50:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-637810 ] "it's" used instead of "its" Message-ID: Bugs item #637810, was opened at 2002-11-13 15:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: "it's" used instead of "its" Initial Comment: I have found two places in the documentation where "it's" appears in a context where "its" is correct: section 13.6.2.3 (it's list of child nodes), 4.2.1 (by it's ordinal value). ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:50 Message: Logged In: YES user_id=418174 Sorry -- the Python library docs (2.2.2). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 15:48 Message: Logged In: YES user_id=3066 Andrew: Section 4.2.1 of which document? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:54:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:54:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:54 Message: Logged In: YES user_id=418174 At this point, I do not believe that any changes to Python are necessary. The main point is for people installing Python on Solaris (and perhaps elsewhere) to realize that they must not use binutils 2.13 or 2.13.1. The attached patch will make binutils 2.13.1 work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 15:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 23:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-20 22:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 17:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 17:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:56:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:56:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-637810 ] "it's" used instead of "its" Message-ID: Bugs item #637810, was opened at 2002-11-13 10:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: "it's" used instead of "its" Initial Comment: I have found two places in the documentation where "it's" appears in a context where "its" is correct: section 13.6.2.3 (it's list of child nodes), 4.2.1 (by it's ordinal value). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 10:56 Message: Logged In: YES user_id=3066 Ok, the problem is only in the 2.2.x library reference; it is not present in the 2.3 version where I was looking. Fixed in Doc/lib/libre.tex revision 1.73.6.12 and Doc/lib/xmldom.tex revisions 1.22 and 1.19.6.2. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:50 Message: Logged In: YES user_id=418174 Sorry -- the Python library docs (2.2.2). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 10:48 Message: Logged In: YES user_id=3066 Andrew: Section 4.2.1 of which document? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637810&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:59:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:59:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:59 Message: Logged In: YES user_id=418174 Here is a patch (to binutils) that makes it possible to build Python with binutils 2.13.1. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:54 Message: Logged In: YES user_id=418174 At this point, I do not believe that any changes to Python are necessary. The main point is for people installing Python on Solaris (and perhaps elsewhere) to realize that they must not use binutils 2.13 or 2.13.1. The attached patch will make binutils 2.13.1 work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 15:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 15:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 23:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-20 22:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 17:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 17:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Wed Nov 13 15:16:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 07:16:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-424106 ] PyImport_ExecCodeModule not correct Message-ID: Bugs item #424106, was opened at 2001-05-14 21:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Richard Jones (richard) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyImport_ExecCodeModule not correct Initial Comment: PyImport_ExecCodeModule doesn't handle package imports correctly. Using it to import a module "A.B" will result in an entry in sys.modules of "A.B" but no information for module "A" will be created. The documentation in the C API reference makes no statement about this - just that the module name may be of the form "package.module". Looking at the code in import.c, there is definitely no handling of the package. If this is the intended behaviour, please amend the documentation (and possibly give some hint as to how one _should_ go about importing a code object in a package structure ;) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 10:16 Message: Logged In: YES user_id=3066 Fixed in Doc/api/utilities.tex revisions 1.7 and 1.3.8.2. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-08-11 23:03 Message: Logged In: YES user_id=6405 I might be missing something, but when I used this call, I couldn't find anything else that let me import a code object into a package. I ended up delving into the source code to attempt to "do the right thing". I can provide the code I wrote to integrate the imported package/module into sys.modules, if you like. Unfortunately, I don't have the code on me at the moment. I think that if this function shouldn't handle the package case then there should be another function that does... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 14:33 Message: Logged In: YES user_id=6380 It's a documentation issue. This is a very low-level helper API in the set of import APIs. The package handling is done by the higher-level import APIs. If you want to fake importing A.B by providing a code object, you will have to also fake the other stuff. I'm leaving this open as a documentation issue, but beware that this stuff is tricky -- your best bet is to study the source code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-09 14:15 Message: Logged In: YES user_id=31435 Assigned to Guido cuz he understands this stuff much better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470 From noreply@sourceforge.net Wed Nov 13 16:31:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 08:31:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-637807 ] \optional in \funcline, \methodline args lists broken Message-ID: Bugs item #637807, was opened at 2002-11-13 10:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637807&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: \optional in \funcline, \methodline args lists broken Initial Comment: In section 4.2.5 ("Match Objects"), the "start" and "end" methods are described as "start([group])" and "end([group])". In both cases, "group" is (corectly) in italics, but in the case of "end", the square brackets surrounding "group" are also italicized. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 11:31 Message: Logged In: YES user_id=3066 Unfortunately, this is a tool problem, not a minor typo. This affects both 2.2.x and 2.3. Updating summary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637807&group_id=5470 From noreply@sourceforge.net Wed Nov 13 16:33:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 08:33:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 11:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Wed Nov 13 16:33:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 08:33:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 11:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Nobody/Anonymous (nobody) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Wed Nov 13 16:41:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 08:41:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 11:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 04:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 03:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 22:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 05:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 04:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 17:13:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 09:13:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-637789 ] httplib doesn't know proxy-connection Message-ID: Bugs item #637789, was opened at 2002-11-13 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637789&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Chih-Chung Chang (jochang) >Assigned to: Jeremy Hylton (jhylton) Summary: httplib doesn't know proxy-connection Initial Comment: HTTPResponse uses the 'connection' header to determine keep-alive or not, but when talking to a proxy server, the 'proxy-connection' header might be used instead. After checking for the 'connection' header, we should also check the 'proxy-connection' header like this: conn = self.msg.getheader('Proxy-Connection') if conn.find('keep-alive') != -1: self.will_close = False ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-11-13 17:13 Message: Logged In: YES user_id=31392 Right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637789&group_id=5470 From noreply@sourceforge.net Wed Nov 13 17:30:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 09:30:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-637789 ] httplib doesn't know proxy-connection Message-ID: Bugs item #637789, was opened at 2002-11-13 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637789&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chih-Chung Chang (jochang) Assigned to: Jeremy Hylton (jhylton) Summary: httplib doesn't know proxy-connection Initial Comment: HTTPResponse uses the 'connection' header to determine keep-alive or not, but when talking to a proxy server, the 'proxy-connection' header might be used instead. After checking for the 'connection' header, we should also check the 'proxy-connection' header like this: conn = self.msg.getheader('Proxy-Connection') if conn.find('keep-alive') != -1: self.will_close = False ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-11-13 17:30 Message: Logged In: YES user_id=31392 Fixed in rev 1.68 of httplib.py. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-11-13 17:13 Message: Logged In: YES user_id=31392 Right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637789&group_id=5470 From noreply@sourceforge.net Wed Nov 13 17:40:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 09:40:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 18:40 Message: Logged In: YES user_id=21627 I still have the plan of adding a comment to README pointing out what binutils releases need to be avoided, but that can be done when we know what binutils release to use. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=418174 Here is a patch (to binutils) that makes it possible to build Python with binutils 2.13.1. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:54 Message: Logged In: YES user_id=418174 At this point, I do not believe that any changes to Python are necessary. The main point is for people installing Python on Solaris (and perhaps elsewhere) to realize that they must not use binutils 2.13 or 2.13.1. The attached patch will make binutils 2.13.1 work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 16:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 01:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-21 00:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 19:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 19:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Wed Nov 13 17:49:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 09:49:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-631683 ] https via httplib trips over IIS defect Message-ID: Bugs item #631683, was opened at 2002-10-31 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631683&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dan Wilder (detroit_dan) Assigned to: Nobody/Anonymous (nobody) Summary: https via httplib trips over IIS defect Initial Comment: When attempting to make a connection via https to an IIS server, for example ssl.pgs.wcom.net deployed by VITAL, the VISAnet on line authorization host, the following exception is encountered: File "./vitalmsg.py", line 130, in ssl_connect^M status, reason, header= hs.getreply()^M File "/usr/lib/python2.2/httplib.py", line 752, in getreply^M response = self._conn.getresponse()^M File "/usr/lib/python2.2/httplib.py", line 593, in getresponse^M response = self.response_class(self.sock)^M File "/usr/lib/python2.2/httplib.py", line 99, in __init__^M self.fp = sock.makefile('rb', 0)^M File "/usr/lib/python2.2/httplib.py", line 628, in makefile^M buf = self.__ssl.read()^M socket.sslerror: (5, 'EOF occurred in violation of protocol')^M As nearly as I can determine, a protocol error has indeed been encountered. However it is unlikely indeed that Microsoft can be induced to correct this, nor that a correction is likely to be deployed by all who use IIS. For reference, the headers returned by the server to a successful request using the attached patch are: Server: Microsoft-IIS/4.0 Date: Tue, 29 Oct 2002 21:57:59 GMT Content-Type: x-data/xact-response The attached patch allows python-2.2.2 to work with this server. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-11-13 17:49 Message: Logged In: YES user_id=31392 This patch has two changes that seem to be completely unrelated. It looks like the httplib.py patch works around the IIS problem and the socket stuff is gratuitous. I don't understand if it's safe to add this workaround for IIS. What an EOF occurs that is a violation of the protocol and means that the client can't recover? It seems this patch could prevent legitimate errors from being corrected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631683&group_id=5470 From noreply@sourceforge.net Wed Nov 13 17:57:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 09:57:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-637807 ] \optional in \funcline args lists broken Message-ID: Bugs item #637807, was opened at 2002-11-13 10:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637807&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: \optional in \funcline args lists broken Initial Comment: In section 4.2.5 ("Match Objects"), the "start" and "end" methods are described as "start([group])" and "end([group])". In both cases, "group" is (corectly) in italics, but in the case of "end", the square brackets surrounding "group" are also italicized. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 12:57 Message: Logged In: YES user_id=3066 Ok, this turns out to be two different things: 1) The wrong markup was used; it used \funcline instead of \methodline. Had it used the right thing, it would have been presented properly. Fixed in Doc/lib/libre.tex revisions 1.92 and 1.73.6.13. 2) \funcline was indeed broken; it needed to be added to a list of macros that needed to have an alternate processing order imposed (it relies on the LaTeX ordering rather than LaTeX2HTML's "inside-out" processing of command arguments). Fixed in Doc/perl/python.perl revisions 1.130 and 1.116.4.5. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 11:31 Message: Logged In: YES user_id=3066 Unfortunately, this is a tool problem, not a minor typo. This affects both 2.2.x and 2.3. Updating summary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637807&group_id=5470 From noreply@sourceforge.net Wed Nov 13 18:25:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 10:25:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Eddy De Greef (edg) Date: 2002-11-13 19:25 Message: Logged In: YES user_id=73597 What if other parts of the code access h_errno indirectly (eg, via libc)? That could still pose thread-safety problems. But I guess this is so unlikely, that it's probably safe. I've applied the patch to 2.2.2 and it compiles and works (without the _XOPEN_SOURCE_EXTENDED flag). Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 17:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 10:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 09:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 04:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 11:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 10:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 18:26:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 10:26:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 19:26 Message: Logged In: YES user_id=21627 I propose a slightly modified patch, but first a few observations: On HPUX10, there is no way to get a thread-safe h_errno, and a h_errno declaration can be obtained by either defining _XOPEN_SOURCE_EXTENDED, or declaring it yourself. On HPUX11, h_errno is always declared (whether or not _XOPEN_SOURCE_EXTENDED is defined). If _REENTRANT is also defined, h_errno is thread-safe and is a macro. If these observations are correct, I think the following patch should satisfy all needs: #if defined(__hpux) && !defined(h_errno) extern int h_errno; #endif What do you think? I'm actually surprised that Neal's patch compiles for HPUX11. Shouldn't this expand to extern int (*__h_errno()); and thus conflict with the earlier declaration of __h_errno as a function? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 19:25 Message: Logged In: YES user_id=73597 What if other parts of the code access h_errno indirectly (eg, via libc)? That could still pose thread-safety problems. But I guess this is so unlikely, that it's probably safe. I've applied the patch to 2.2.2 and it compiles and works (without the _XOPEN_SOURCE_EXTENDED flag). Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 17:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 10:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 09:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 04:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 11:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 10:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 18:35:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 10:35:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 13:35 Message: Logged In: YES user_id=33168 Martin, I agree with both your observations. I don't know why it wasn't a problem on HPUX11. I agree with checking that h_errno is not defined. I will look through the compiler/preprocessor output a bit more and try to make sure everything seems ok before checking in. Eddy, thanks for all your input. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:26 Message: Logged In: YES user_id=21627 I propose a slightly modified patch, but first a few observations: On HPUX10, there is no way to get a thread-safe h_errno, and a h_errno declaration can be obtained by either defining _XOPEN_SOURCE_EXTENDED, or declaring it yourself. On HPUX11, h_errno is always declared (whether or not _XOPEN_SOURCE_EXTENDED is defined). If _REENTRANT is also defined, h_errno is thread-safe and is a macro. If these observations are correct, I think the following patch should satisfy all needs: #if defined(__hpux) && !defined(h_errno) extern int h_errno; #endif What do you think? I'm actually surprised that Neal's patch compiles for HPUX11. Shouldn't this expand to extern int (*__h_errno()); and thus conflict with the earlier declaration of __h_errno as a function? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 13:25 Message: Logged In: YES user_id=73597 What if other parts of the code access h_errno indirectly (eg, via libc)? That could still pose thread-safety problems. But I guess this is so unlikely, that it's probably safe. I've applied the patch to 2.2.2 and it compiles and works (without the _XOPEN_SOURCE_EXTENDED flag). Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 11:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 04:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 03:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 22:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 05:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 04:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 18:58:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 10:58:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 13:58 Message: Logged In: YES user_id=33168 h_errno doesn't get expanded from the macro because it is declared before including netdb.h which defines the macro. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 13:35 Message: Logged In: YES user_id=33168 Martin, I agree with both your observations. I don't know why it wasn't a problem on HPUX11. I agree with checking that h_errno is not defined. I will look through the compiler/preprocessor output a bit more and try to make sure everything seems ok before checking in. Eddy, thanks for all your input. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:26 Message: Logged In: YES user_id=21627 I propose a slightly modified patch, but first a few observations: On HPUX10, there is no way to get a thread-safe h_errno, and a h_errno declaration can be obtained by either defining _XOPEN_SOURCE_EXTENDED, or declaring it yourself. On HPUX11, h_errno is always declared (whether or not _XOPEN_SOURCE_EXTENDED is defined). If _REENTRANT is also defined, h_errno is thread-safe and is a macro. If these observations are correct, I think the following patch should satisfy all needs: #if defined(__hpux) && !defined(h_errno) extern int h_errno; #endif What do you think? I'm actually surprised that Neal's patch compiles for HPUX11. Shouldn't this expand to extern int (*__h_errno()); and thus conflict with the earlier declaration of __h_errno as a function? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 13:25 Message: Logged In: YES user_id=73597 What if other parts of the code access h_errno indirectly (eg, via libc)? That could still pose thread-safety problems. But I guess this is so unlikely, that it's probably safe. I've applied the patch to 2.2.2 and it compiles and works (without the _XOPEN_SOURCE_EXTENDED flag). Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 11:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 04:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 03:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 22:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 05:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 04:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 19:06:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 11:06:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-604128 ] time.struct_time undocumented Message-ID: Bugs item #604128, was opened at 2002-09-03 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.struct_time undocumented Initial Comment: The time module has a mystery name called "struct_time" which is undocumented. It is used in a couple of places such as imaplib.py, test_structseq.py and test_strptime.py. It should be documented. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 14:06 Message: Logged In: YES user_id=3066 We'll skip renaming the type for now, since there's no consistency regarding the names of the "structured sequence" types. Since the type was already named and released in the 2.2.x series, we can't really get rid of the old name anyway. I've updated the documentation to reflect the addition of the struct_time type and the attribute names for fields in Doc/lib/libtime.tex revisions 1.51 and 1.48.6.2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-11-02 14:47 Message: Logged In: YES user_id=357491 If an agreement can be reached on what it should be renamed to (I thought we had agreed on a name already? I, of course, don't have the email to prove this, though), I am willing to help grep Lib/ and generate patches to replace the calls with the new name (and I will even use unified diffs this time! =). Personally, I think TimeStructType is fine, but we must make sure that it won't be mistaken for the forthcoming datetime type. I would wager that the datetime type would have something named DateTimeType if there is going to be a name that might conflict. I am also willing to write the blurb to document this sucker. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 21:57 Message: Logged In: YES user_id=12800 It should also be renamed to be something like TimeStructType. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604128&group_id=5470 From noreply@sourceforge.net Wed Nov 13 19:12:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 11:12:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 17:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 20:12 Message: Logged In: YES user_id=21627 In that case, the patch is, strictly speaking, correct: the external definition won't be used if a #define comes along later. It seems to be cleaner to declare it after including netdb, and only if it wasn't defined. Unless testing such an approach reveals further insights, I trust you that you will implement something that works well on all considered systems - just go ahead an implement what you like most. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 19:58 Message: Logged In: YES user_id=33168 h_errno doesn't get expanded from the macro because it is declared before including netdb.h which defines the macro. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 19:35 Message: Logged In: YES user_id=33168 Martin, I agree with both your observations. I don't know why it wasn't a problem on HPUX11. I agree with checking that h_errno is not defined. I will look through the compiler/preprocessor output a bit more and try to make sure everything seems ok before checking in. Eddy, thanks for all your input. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 19:26 Message: Logged In: YES user_id=21627 I propose a slightly modified patch, but first a few observations: On HPUX10, there is no way to get a thread-safe h_errno, and a h_errno declaration can be obtained by either defining _XOPEN_SOURCE_EXTENDED, or declaring it yourself. On HPUX11, h_errno is always declared (whether or not _XOPEN_SOURCE_EXTENDED is defined). If _REENTRANT is also defined, h_errno is thread-safe and is a macro. If these observations are correct, I think the following patch should satisfy all needs: #if defined(__hpux) && !defined(h_errno) extern int h_errno; #endif What do you think? I'm actually surprised that Neal's patch compiles for HPUX11. Shouldn't this expand to extern int (*__h_errno()); and thus conflict with the earlier declaration of __h_errno as a function? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 19:25 Message: Logged In: YES user_id=73597 What if other parts of the code access h_errno indirectly (eg, via libc)? That could still pose thread-safety problems. But I guess this is so unlikely, that it's probably safe. I've applied the patch to 2.2.2 and it compiles and works (without the _XOPEN_SOURCE_EXTENDED flag). Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 17:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 10:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 09:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 04:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 11:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 10:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 22:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Wed Nov 13 19:26:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 11:26:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-637941 ] __getstate__() documenting is vague Message-ID: Bugs item #637941, was opened at 2002-11-13 19:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637941&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: __getstate__() documenting is vague Initial Comment: If you write a getstate / setstate pair for a new-style type so that it can be pickled, the reduce code for new-style types imposes extra restrictions on the getstate / setstate pair. Specifically, the setstate method will be called only if the object returned by getstate is not false. The reconstructor code uses the variable "dict" for the getstate result. This suggests that it must be a dict, although I can't tell if that is actually true. If it is an empty dict, setstate won't be called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637941&group_id=5470 From noreply@sourceforge.net Wed Nov 13 19:30:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 11:30:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-637941 ] __getstate__() documenting is vague Message-ID: Bugs item #637941, was opened at 2002-11-13 14:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637941&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __getstate__() documenting is vague Initial Comment: If you write a getstate / setstate pair for a new-style type so that it can be pickled, the reduce code for new-style types imposes extra restrictions on the getstate / setstate pair. Specifically, the setstate method will be called only if the object returned by getstate is not false. The reconstructor code uses the variable "dict" for the getstate result. This suggests that it must be a dict, although I can't tell if that is actually true. If it is an empty dict, setstate won't be called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637941&group_id=5470 From noreply@sourceforge.net Wed Nov 13 20:16:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 12:16:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-486360 ] Support for page & shortcut icons Message-ID: Bugs item #486360, was opened at 2001-11-28 00:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=486360&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Support for page & shortcut icons Initial Comment: The generated Python documentation should include support for "page" and "shortcut" icons. These are supported (at least) by MSIE and Mozilla 0.9.6 ("page" only for now, but "shortcut" expected for 0.9.7). Netscape 6.x will acquire support from the Mozilla project. More information: http://www.mozilla.org/releases/mozilla0.9.6/ http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-13 15:16 Message: Logged In: YES user_id=3066 Neal: Yes, I did. Cosing now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:36 Message: Logged In: YES user_id=33168 Fred, did you just check in this change? Should this be closed? http://mail.python.org/pipermail/python-checkins/2002-October/030437.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=486360&group_id=5470 From noreply@sourceforge.net Wed Nov 13 21:14:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 13:14:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 11:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: A.M. Kuchling (akuchling) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:14 Message: Logged In: YES user_id=11375 Snarfed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Wed Nov 13 21:38:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 13:38:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Nov 13 21:42:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 13:42:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Nov 13 21:47:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 13:47:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Nov 13 21:59:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 13:59:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Nov 13 22:03:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 14:03:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-631683 ] https via httplib trips over IIS defect Message-ID: Bugs item #631683, was opened at 2002-10-31 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631683&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Dan Wilder (detroit_dan) Assigned to: Nobody/Anonymous (nobody) Summary: https via httplib trips over IIS defect Initial Comment: When attempting to make a connection via https to an IIS server, for example ssl.pgs.wcom.net deployed by VITAL, the VISAnet on line authorization host, the following exception is encountered: File "./vitalmsg.py", line 130, in ssl_connect^M status, reason, header= hs.getreply()^M File "/usr/lib/python2.2/httplib.py", line 752, in getreply^M response = self._conn.getresponse()^M File "/usr/lib/python2.2/httplib.py", line 593, in getresponse^M response = self.response_class(self.sock)^M File "/usr/lib/python2.2/httplib.py", line 99, in __init__^M self.fp = sock.makefile('rb', 0)^M File "/usr/lib/python2.2/httplib.py", line 628, in makefile^M buf = self.__ssl.read()^M socket.sslerror: (5, 'EOF occurred in violation of protocol')^M As nearly as I can determine, a protocol error has indeed been encountered. However it is unlikely indeed that Microsoft can be induced to correct this, nor that a correction is likely to be deployed by all who use IIS. For reference, the headers returned by the server to a successful request using the attached patch are: Server: Microsoft-IIS/4.0 Date: Tue, 29 Oct 2002 21:57:59 GMT Content-Type: x-data/xact-response The attached patch allows python-2.2.2 to work with this server. ---------------------------------------------------------------------- >Comment By: Dan Wilder (detroit_dan) Date: 2002-11-13 14:03 Message: Logged In: YES user_id=639879 Problem has been reported previously and is apparently resolved in Python-2.3. See item number 500311. Attached patch was erroneously believed by me to be the work of a developer I'm working with; upon contacting him, I discovered that it was none other than work previously submitted to this site by vdbergh! My misunderstanding. Apologies. Please consider item closed. -- Dan Wilder ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-11-13 09:49 Message: Logged In: YES user_id=31392 This patch has two changes that seem to be completely unrelated. It looks like the httplib.py patch works around the IIS problem and the socket stuff is gratuitous. I don't understand if it's safe to add this workaround for IIS. What an EOF occurs that is a violation of the protocol and means that the client can't recover? It seems this patch could prevent legitimate errors from being corrected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631683&group_id=5470 From noreply@sourceforge.net Thu Nov 14 01:24:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 17:24:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 10:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Skip Montanaro (montanaro) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 15:14 Message: Logged In: YES user_id=11375 Snarfed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Thu Nov 14 01:30:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 17:30:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Thu Nov 14 01:45:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 17:45:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-550364 ] Version number handling Message-ID: Bugs item #550364, was opened at 2002-04-29 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Version number handling Initial Comment: A while ago, Tim Peters mentioned in a check-in message: "Change the version string from "2.2+" to "2.3a0". distutils peels off the first 3 characters of this string in several places, so for as long as they remain "2.2" it confuses the heck out of attempts to build 2.3 stuff using distutils." It's true; distutils does sys.version[:3] in a few places. The attached patch factors this out so it'll be easier to change. (There's also a Python development issue here, namely when the version number gets bumped in the CVS tree.) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:45 Message: Logged In: YES user_id=11375 Checked in, since MAL argued convincingly for maintaining 1.5.2 support. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:53 Message: Logged In: YES user_id=11375 Probably we can just use sys.version_info, since we don't care about 1.5.2 any more. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-25 12:12 Message: Logged In: YES user_id=31392 Do we still care about this patch? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-05-15 16:54 Message: Logged In: YES user_id=11375 Maybe. But I don't know if I still care about 1.5.2. If I don't, then the code can just always use sys.version_info. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 06:51 Message: Logged In: YES user_id=80475 Nice factoring. Would it be more bulletproof to use sys.version_info instead of sys.version[:3]? Perhaps, wrap it in try/except to catch versions before Py2.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470 From noreply@sourceforge.net Thu Nov 14 01:53:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 17:53:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-569668 ] LINKCC incorrectly set Message-ID: Bugs item #569668, was opened at 2002-06-16 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Dr Leonid A Timochouk (cardou) >Assigned to: A.M. Kuchling (akuchling) Summary: LINKCC incorrectly set Initial Comment: I was building Python 2.2.1 on Debian/GNU Linux 3.0 (testing pre-release) with gcc and g++ of version 3.0.4, using --with-cxx=g++ configure option. Then linking of the "python" executable fails due to an unresolved symbol (__gxx_personality_v0) in Modules/ccpython.o, because linking is still done with gcc: LINKCC is set to gcc ($CC) by configure, rather than to g++ ($CXX). The configure script attempts to determine the value of LINKCC and sets it to $CC if the latter can successfully link the simplest program "int main(){return 0;}" which was compiled with $CXX. In this case, linking apparently succeeds, setting LINKCC to $CC. Yet linking of Modules/ccpython.o with $CC fails, probably because Modules/ccpython.c is slightly more complex than the above configuration test, hence an extra unresolved symbol generated by g++. I am not sure how the correct value of LINKCC can be determined at config time without unnecessarily using $CXX all the time when it is available. Maybe the makefile should be modified so it always starts from $CC and falls through to $CXX if the former fails? Sincerely, Dr. Leonid Timochouk Computing Laboratory University of Kent at Canterbury England ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:29 Message: Logged In: YES user_id=33168 I believe there were some changes made which should fix this problem. Can you try the latest CVS for the 2.2 branch or 2.3? cvs update -r release22-maint will get the 2.2.1+ version (what will become 2.2.2). Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470 From noreply@sourceforge.net Thu Nov 14 02:22:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 18:22:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Neal Norwitz (nnorwitz) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 21:22 Message: Logged In: YES user_id=33168 Checked in as Modules/socketmodule.c 1.200.6.10 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 14:12 Message: Logged In: YES user_id=21627 In that case, the patch is, strictly speaking, correct: the external definition won't be used if a #define comes along later. It seems to be cleaner to declare it after including netdb, and only if it wasn't defined. Unless testing such an approach reveals further insights, I trust you that you will implement something that works well on all considered systems - just go ahead an implement what you like most. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 13:58 Message: Logged In: YES user_id=33168 h_errno doesn't get expanded from the macro because it is declared before including netdb.h which defines the macro. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 13:35 Message: Logged In: YES user_id=33168 Martin, I agree with both your observations. I don't know why it wasn't a problem on HPUX11. I agree with checking that h_errno is not defined. I will look through the compiler/preprocessor output a bit more and try to make sure everything seems ok before checking in. Eddy, thanks for all your input. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:26 Message: Logged In: YES user_id=21627 I propose a slightly modified patch, but first a few observations: On HPUX10, there is no way to get a thread-safe h_errno, and a h_errno declaration can be obtained by either defining _XOPEN_SOURCE_EXTENDED, or declaring it yourself. On HPUX11, h_errno is always declared (whether or not _XOPEN_SOURCE_EXTENDED is defined). If _REENTRANT is also defined, h_errno is thread-safe and is a macro. If these observations are correct, I think the following patch should satisfy all needs: #if defined(__hpux) && !defined(h_errno) extern int h_errno; #endif What do you think? I'm actually surprised that Neal's patch compiles for HPUX11. Shouldn't this expand to extern int (*__h_errno()); and thus conflict with the earlier declaration of __h_errno as a function? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 13:25 Message: Logged In: YES user_id=73597 What if other parts of the code access h_errno indirectly (eg, via libc)? That could still pose thread-safety problems. But I guess this is so unlikely, that it's probably safe. I've applied the patch to 2.2.2 and it compiles and works (without the _XOPEN_SOURCE_EXTENDED flag). Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 11:41 Message: Logged In: YES user_id=33168 On HPUX 11, socketmodule.c builds fine with or without the patch. All the tests run successfully with or without this patch. Since python provides its own lock (see USE_GETHOSTBYNAME_LOCK) around access to h_errno (actually gethost_common() which accesses h_errno), it seems to me the usage will still be thread safe. The reason to not use _XOPEN_SOURCE_EXTENDED is the potential breakage. Especially since this is working on HPUX11. I don't see any way to distinguish between HPUX10 and HPUX11. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-13 04:01 Message: Logged In: YES user_id=73597 As I wrote before, this patch is not thread-safe on HPUX11 (see the man page section below), so I don't think it should be applied. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 03:34 Message: Logged In: YES user_id=21627 Since Eddy indicated that that patch helps on HP-UX 10 as well, and since it definitely won't break other systems, I think this is a good idea, please apply it. For 2.3, the definition of _XOPEN_SOURCE_EXTENDED should be sufficient. So I think you can safely close this after you've applied the patch; if Eddy finds further problems on HPUX10, he should then submit a new report. Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 22:33 Message: Logged In: YES user_id=33168 Martin, do you think it is acceptable to add the patch below to the 2.2.2 branch? Do you have any ideas for a better patch? I don't have access to HPUX 10, I only have access to HPUX 11. If this patch is acceptable, assign back to me. I will test it on HPUX 11 to make sure it doesn't break. Eddy, if Martin accepts this, could you also test that patch to verify that 2.2.2 works? +++ Modules/socketmodule.c 13 Nov 2002 03:29:55 -0000 @@ -130,6 +130,9 @@ #include #endif +#if defined(__hpux) +extern int h_errno; +#endif #include ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-11-04 05:45 Message: Logged In: YES user_id=73597 I've downloaded the latest 2.3 snapshot (11-4) and it is indeed fixed, thanks. Yes, I still had the problem with 2.2.2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 15:07 Message: Logged In: YES user_id=33168 Eddy, _XOPEN_SOURCE_EXTENDED is now defined in pyconfig.h for 2.3. Can you verify this fixes your problem? Are you still having a problem with 2.2.2? ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-22 04:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 16:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Thu Nov 14 02:29:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 18:29:42 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-520382 ] Update Shelve to be more dictionary like Message-ID: Feature Requests item #520382, was opened at 2002-02-20 03:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Guido van Rossum (gvanrossum) Summary: Update Shelve to be more dictionary like Initial Comment: It's great to be able to add persistence by replacing a dictionary declaration with a shelf; however, it is not as substitutable as it could be. Most importantly, we should add __iter__ so that 'for k in d' works for shelves as well as dictionaries. Also add .items .iteritems .iterkeys .itervalues .popitem . setdefault .update and .values These methods could be added to increase substitutability without affecting existing code. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=80475 Here is a concept sketch patch for expanding the shelve interface. The goal is to make it is easier to add persistence when an application was already developed using dictionaries as a base. On a separate note, DictMixin is offered as a stand-alone class to make it easier to create classes with a full dictionary interface. On py-dev, we concluded that DictMixin did not warrant its own module, so this would be a good place to expose the mixin class as an experimental feature while taking care of shelve at the same time. If the concept sketch appeals to you, I'll add docs, unittests, and a news item. DictMixin would be listed as experimental and potentially would not be visible in future versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 From noreply@sourceforge.net Thu Nov 14 03:39:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 19:39:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-636648 ] os.path.normpath leading '//' Message-ID: Bugs item #636648, was opened at 2002-11-11 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nicholas Jones (carpaski) >Assigned to: Neal Norwitz (nnorwitz) Summary: os.path.normpath leading '//' Initial Comment: normpath does not remove leading double slashes. (Linux) Python 2.2.1 (#1, Oct 30 2002, 19:46:40) >>> import os.path >>> os.path.normpath("//usr/bin") '//usr/bin' >>> os.path.normpath("///usr/bin") '/usr/bin' >>> os.path.normpath("//./usr/bin") '//usr/bin' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 22:39 Message: Logged In: YES user_id=33168 This is the intent of the code. The comment says: # POSIX allows one or two initial slashes, but treats three or more # as single slash. Therefore, I'm closing this as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636648&group_id=5470 From noreply@sourceforge.net Thu Nov 14 03:43:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 19:43:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 03:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Michael Hudson (mwh) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 22:43 Message: Logged In: YES user_id=33168 Michael is there still a bug here or should this be closed? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-11 07:26 Message: Logged In: YES user_id=580910 I already have an NSArray proxy (actually a module that proxies the entire Cocoa classtree on MacOS X). The NSArray proxy is not a subclass of list but part of a class hierarchy that mirrors that of the proxied classes (the code is available from pyobjc.sourceforge.net). The reason I ran into this bug is that someone suggested that subclassing list might be a good solution for using an NSArray as the source for slice assigment on lists. Thanks to your previous patch that is no longer an issue. It might be usefull to add functions that check if it is save to directly access the list representation. Even though it might not be sensible to do so, it is possible to change __getitem__ et. al. from Python code and it would be very strange if the version of those methods from subclasses is sometimes ignored. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-11 06:50 Message: Logged In: YES user_id=6656 I've thought about this a bit. You're writing a NSArray proxy, right? Here's some advice: do NOT inherit from list. What does inheriting from list get you? The ability to pass `PyList_Check'. But almost inevitably code that calls that promptly pokes into the internal structure of the list. For example, you'll find iterating over your proxy list doesn't respect the subtype (unless you supply an __iter__ method, I guess/hope). If you find things that fail because of this, let's fix those to take more general sequences. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-06 06:21 Message: Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 03:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 13:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 06:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Thu Nov 14 04:02:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 20:02:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 10:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-11-13 22:02 Message: Logged In: YES user_id=44345 Assigning back to Fred. Initial cut at liblogging.tex is checked in. It's essentially just a mechanical translation of pydoc.help(logging). Note that Vinay's documentation at http://www.red-dove.com/python_logging.html has not been converted. This still needs to be done. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 15:14 Message: Logged In: YES user_id=11375 Snarfed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Thu Nov 14 04:06:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 20:06:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-638126 ] logging module not installed Message-ID: Bugs item #638126, was opened at 2002-11-13 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638126&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Guido van Rossum (gvanrossum) Summary: logging module not installed Initial Comment: The new logging package doesn't seem to be installed by "make install", at least not on my MacOSX system. Assigning to Guido because he just checked it into CVS. Haven't looked into the problem at all (gotta get to bed and get rid of this cold...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638126&group_id=5470 From noreply@sourceforge.net Thu Nov 14 04:12:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 20:12:19 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-520382 ] Update Shelve to be more dictionary like Message-ID: Feature Requests item #520382, was opened at 2002-02-20 03:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Update Shelve to be more dictionary like Initial Comment: It's great to be able to add persistence by replacing a dictionary declaration with a shelf; however, it is not as substitutable as it could be. Most importantly, we should add __iter__ so that 'for k in d' works for shelves as well as dictionaries. Also add .items .iteritems .iterkeys .itervalues .popitem . setdefault .update and .values These methods could be added to increase substitutability without affecting existing code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-13 23:12 Message: Logged In: YES user_id=6380 What's py-dev? I don't recall a discussion on DictMixin on python-dev, so is it something different, maybe IRC? Maybe DIctMixin can live in UserDict? has_key() should not call keys(); it should try self[key] and catch the KeyError. __contains__ should just be an alias for has_key rather than a wrapper. But those are all details; I like the ideas here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=80475 Here is a concept sketch patch for expanding the shelve interface. The goal is to make it is easier to add persistence when an application was already developed using dictionaries as a base. On a separate note, DictMixin is offered as a stand-alone class to make it easier to create classes with a full dictionary interface. On py-dev, we concluded that DictMixin did not warrant its own module, so this would be a good place to expose the mixin class as an experimental feature while taking care of shelve at the same time. If the concept sketch appeals to you, I'll add docs, unittests, and a news item. DictMixin would be listed as experimental and potentially would not be visible in future versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 From noreply@sourceforge.net Thu Nov 14 04:56:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 20:56:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-638126 ] logging module not installed Message-ID: Bugs item #638126, was opened at 2002-11-13 23:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638126&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) Summary: logging module not installed Initial Comment: The new logging package doesn't seem to be installed by "make install", at least not on my MacOSX system. Assigning to Guido because he just checked it into CVS. Haven't looked into the problem at all (gotta get to bed and get rid of this cold...) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 23:56 Message: Logged In: YES user_id=33168 Checked in as Makefile.pre.in 1.102 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638126&group_id=5470 From noreply@sourceforge.net Thu Nov 14 06:09:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 22:09:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 19:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) Assigned to: Neal Norwitz (nnorwitz) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-14 06:09 Message: Logged In: YES user_id=33229 the answer is just (untested) return list (self.tk.split(self.tk.call(self._w, 'getselection', mode ))) isn't it? I'll test it out and contribute an updated version of Tix.py - it looks like there may be some others that should be using return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:57 Message: Logged In: YES user_id=33168 I've got mail from Mike Clarkson with other changes in Tix. I will sync up with Mike and fix this problem (he confirmed this is bug.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-15 00:42 Message: Logged In: YES user_id=6380 idiscovery, can you mail me a patch? ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 20:10 Message: Logged In: YES user_id=626964 Forgot the case with no selection: def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: if len(x) > 0: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 19:57 Message: Logged In: YES user_id=626964 You are right. How would this look? def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-10-11 17:14 Message: Logged In: YES user_id=33229 You're right - there should be values returned. Ideally, getselection should return a Python list, not just a Tcl string which is a list to Tcl. Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Thu Nov 14 06:44:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Nov 2002 22:44:30 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-520382 ] Update Shelve to be more dictionary like Message-ID: Feature Requests item #520382, was opened at 2002-02-20 03:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Guido van Rossum (gvanrossum) Summary: Update Shelve to be more dictionary like Initial Comment: It's great to be able to add persistence by replacing a dictionary declaration with a shelf; however, it is not as substitutable as it could be. Most importantly, we should add __iter__ so that 'for k in d' works for shelves as well as dictionaries. Also add .items .iteritems .iterkeys .itervalues .popitem . setdefault .update and .values These methods could be added to increase substitutability without affecting existing code. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-14 01:44 Message: Logged In: YES user_id=80475 Yes. DictMixin moved to UserDict. Yes. has_key() now uses try/except (much better). Yes. __contains__ aliased to has_key Added news item and docs. See new patch below. If the design is acceptable, I'll move on to writing the unittests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-13 23:12 Message: Logged In: YES user_id=6380 What's py-dev? I don't recall a discussion on DictMixin on python-dev, so is it something different, maybe IRC? Maybe DIctMixin can live in UserDict? has_key() should not call keys(); it should try self[key] and catch the KeyError. __contains__ should just be an alias for has_key rather than a wrapper. But those are all details; I like the ideas here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=80475 Here is a concept sketch patch for expanding the shelve interface. The goal is to make it is easier to add persistence when an application was already developed using dictionaries as a base. On a separate note, DictMixin is offered as a stand-alone class to make it easier to create classes with a full dictionary interface. On py-dev, we concluded that DictMixin did not warrant its own module, so this would be a good place to expose the mixin class as an experimental feature while taking care of shelve at the same time. If the concept sketch appeals to you, I'll add docs, unittests, and a news item. DictMixin would be listed as experimental and potentially would not be visible in future versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 From noreply@sourceforge.net Thu Nov 14 08:29:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 00:29:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 14:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius Gedminas (mgedmin) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 09:29 Message: Logged In: YES user_id=21627 I think the processing of the error condition is wrong, in a number of ways: - Posix allows for both EAGAIN and EWOULDBLOCK to be signalled in this case. - Neither EAGAIN nor EWOULDBLOCK are guaranteed to exist on all systems. - Please add a comment to the break; to indicate what the purpose of this code is. Also, I think there are a number of other cases where bytesread might be non-zero, e.g. if EINTR was signalled. It's not clear what the best solution would be, I propose that the exception carries an attribute "data" to denote the short data. Of course, in the EINTR case, the original exception is lost and a KeyboardInterrupt is raised instead, so putting the data into the exception might be pointless... In any case, please update the documentation to describe the special cases that you add. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 17:43 Message: Logged In: YES user_id=7887 Martin, could you please review that? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 16:58 Message: Logged In: YES user_id=7887 Great catch Marius! Thank you very much! I could identify the following problems from your report: - If (requestsize == -1) and after a few iterations, fread() signals EWOULDBLOCK with (chunksize == 0), all read data is lost because an exception is raised. - When (chunksize != 0) and EWOULDBLOCK is signaled, ferror() will be flagged. Then the next iteration will fail if: 1) read data has length 0 because EWOULDBLOCK is signaled again but errno is still set to 0 (I don't know why errno is not reset in that case); 2) read data has length 0 because a block with the exact requested size is read. The attached tests show these problems. The first problem is a little bit harder to trigger. I had to preset SMALLCHUNK to 4096 in fileobject.c, because my Linux refused to return a chunk greater than that from fread(). The second problem should be visible without further tweakings. I have also attached a solution to the problem. This solution works because: - If (chunksize == 0), (errno == EWOULDBLOCK) and (readbytes > 0), there's no point in raising an exception, as we got some data for the user, just like when (bytesread < buffersize). - When (chunksize != 0) and EWOULDBLOCK is signaled, it's not considered an error. OTOH, ferror() is still being set. clearerr() should be called in the stream before breaking the loop. - If (bytesread == buffersize) and (bytesrequest >= 0), it means that we already got all the requested data, and thus there's no point in trying to read more data from the file and forcing (chunksize == 0) without ferror() being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Thu Nov 14 12:58:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 04:58:02 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-520382 ] Update Shelve to be more dictionary like Message-ID: Feature Requests item #520382, was opened at 2002-02-20 03:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Update Shelve to be more dictionary like Initial Comment: It's great to be able to add persistence by replacing a dictionary declaration with a shelf; however, it is not as substitutable as it could be. Most importantly, we should add __iter__ so that 'for k in d' works for shelves as well as dictionaries. Also add .items .iteritems .iterkeys .itervalues .popitem . setdefault .update and .values These methods could be added to increase substitutability without affecting existing code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 07:58 Message: Logged In: YES user_id=6380 Please go ahead. I'll apply my minor quibbles once it's in CVS. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-14 01:44 Message: Logged In: YES user_id=80475 Yes. DictMixin moved to UserDict. Yes. has_key() now uses try/except (much better). Yes. __contains__ aliased to has_key Added news item and docs. See new patch below. If the design is acceptable, I'll move on to writing the unittests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-13 23:12 Message: Logged In: YES user_id=6380 What's py-dev? I don't recall a discussion on DictMixin on python-dev, so is it something different, maybe IRC? Maybe DIctMixin can live in UserDict? has_key() should not call keys(); it should try self[key] and catch the KeyError. __contains__ should just be an alias for has_key rather than a wrapper. But those are all details; I like the ideas here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=80475 Here is a concept sketch patch for expanding the shelve interface. The goal is to make it is easier to add persistence when an application was already developed using dictionaries as a base. On a separate note, DictMixin is offered as a stand-alone class to make it easier to create classes with a full dictionary interface. On py-dev, we concluded that DictMixin did not warrant its own module, so this would be a good place to expose the mixin class as an experimental feature while taking care of shelve at the same time. If the concept sketch appeals to you, I'll add docs, unittests, and a news item. DictMixin would be listed as experimental and potentially would not be visible in future versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 From noreply@sourceforge.net Thu Nov 14 12:58:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 04:58:19 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-520382 ] Update Shelve to be more dictionary like Message-ID: Feature Requests item #520382, was opened at 2002-02-20 03:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Update Shelve to be more dictionary like Initial Comment: It's great to be able to add persistence by replacing a dictionary declaration with a shelf; however, it is not as substitutable as it could be. Most importantly, we should add __iter__ so that 'for k in d' works for shelves as well as dictionaries. Also add .items .iteritems .iterkeys .itervalues .popitem . setdefault .update and .values These methods could be added to increase substitutability without affecting existing code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 07:58 Message: Logged In: YES user_id=6380 Please go ahead. I'll apply my minor quibbles once it's in CVS. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-14 01:44 Message: Logged In: YES user_id=80475 Yes. DictMixin moved to UserDict. Yes. has_key() now uses try/except (much better). Yes. __contains__ aliased to has_key Added news item and docs. See new patch below. If the design is acceptable, I'll move on to writing the unittests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-13 23:12 Message: Logged In: YES user_id=6380 What's py-dev? I don't recall a discussion on DictMixin on python-dev, so is it something different, maybe IRC? Maybe DIctMixin can live in UserDict? has_key() should not call keys(); it should try self[key] and catch the KeyError. __contains__ should just be an alias for has_key rather than a wrapper. But those are all details; I like the ideas here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=80475 Here is a concept sketch patch for expanding the shelve interface. The goal is to make it is easier to add persistence when an application was already developed using dictionaries as a base. On a separate note, DictMixin is offered as a stand-alone class to make it easier to create classes with a full dictionary interface. On py-dev, we concluded that DictMixin did not warrant its own module, so this would be a good place to expose the mixin class as an experimental feature while taking care of shelve at the same time. If the concept sketch appeals to you, I'll add docs, unittests, and a news item. DictMixin would be listed as experimental and potentially would not be visible in future versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 From noreply@sourceforge.net Thu Nov 14 13:23:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 05:23:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 08:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Michael Hudson (mwh) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-11-14 13:23 Message: Logged In: YES user_id=6656 Not sure :-/ Actually, the extended slices stuff should grow to accept non-lists on the RHS, so the report should stay open. What's less clear is whether tuple(list_subtype) should respect the subtype. There are so many places where the subtype is not respected, I'm inclined to leave it be. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 03:43 Message: Logged In: YES user_id=33168 Michael is there still a bug here or should this be closed? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-11 12:26 Message: Logged In: YES user_id=580910 I already have an NSArray proxy (actually a module that proxies the entire Cocoa classtree on MacOS X). The NSArray proxy is not a subclass of list but part of a class hierarchy that mirrors that of the proxied classes (the code is available from pyobjc.sourceforge.net). The reason I ran into this bug is that someone suggested that subclassing list might be a good solution for using an NSArray as the source for slice assigment on lists. Thanks to your previous patch that is no longer an issue. It might be usefull to add functions that check if it is save to directly access the list representation. Even though it might not be sensible to do so, it is possible to change __getitem__ et. al. from Python code and it would be very strange if the version of those methods from subclasses is sometimes ignored. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-11 11:50 Message: Logged In: YES user_id=6656 I've thought about this a bit. You're writing a NSArray proxy, right? Here's some advice: do NOT inherit from list. What does inheriting from list get you? The ability to pass `PyList_Check'. But almost inevitably code that calls that promptly pokes into the internal structure of the list. For example, you'll find iterating over your proxy list doesn't respect the subtype (unless you supply an __iter__ method, I guess/hope). If you find things that fail because of this, let's fix those to take more general sequences. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-06 11:21 Message: Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 08:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 18:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 11:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Thu Nov 14 15:15:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 07:15:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 10:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Skip Montanaro (montanaro) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-11-14 09:15 Message: Logged In: YES user_id=44345 taking it back - fred ya gotta be quick around here! ;-) Got some new content from Vinay which I'll either merge with what I did or use to replace it in its entirety... See http://python.org/sf/638299 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-13 22:02 Message: Logged In: YES user_id=44345 Assigning back to Fred. Initial cut at liblogging.tex is checked in. It's essentially just a mechanical translation of pydoc.help(logging). Note that Vinay's documentation at http://www.red-dove.com/python_logging.html has not been converted. This still needs to be done. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 15:14 Message: Logged In: YES user_id=11375 Snarfed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Thu Nov 14 16:24:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 08:24:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-637941 ] __getstate__() documentation is vague Message-ID: Bugs item #637941, was opened at 2002-11-13 14:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637941&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: __getstate__() documentation is vague Initial Comment: If you write a getstate / setstate pair for a new-style type so that it can be pickled, the reduce code for new-style types imposes extra restrictions on the getstate / setstate pair. Specifically, the setstate method will be called only if the object returned by getstate is not false. The reconstructor code uses the variable "dict" for the getstate result. This suggests that it must be a dict, although I can't tell if that is actually true. If it is an empty dict, setstate won't be called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637941&group_id=5470 From noreply@sourceforge.net Thu Nov 14 16:41:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 08:41:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-501622 ] Missing trailing \n should not raise SyntaxError Message-ID: Bugs item #501622, was opened at 2002-01-09 23:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bolen (db3l) Assigned to: Guido van Rossum (gvanrossum) >Summary: Missing trailing \n should not raise SyntaxError Initial Comment: If you have a module that you wish to compile using the builtin compile() function (in 'exec' mode), it will fail with a SyntaxError if that module does not have a newline as its final token. The same module can be executed directly by the interpreter, or imported by another module, and Python can properly compile and save a pyc for the module. I believe the difference is rooted in the fact that the tokenizer (tokenizer.c, in tok_nextc()) will "fake" a newline at the end of a file if it doesn't find one, but it will not do so when tokenizing a string buffer. What I'm not certain of is whether faking such a token for strings as well won't break something else (such as when parsing a string for an expression rather than a full module). But without such a change, you have a state where a module that works (and compiles) in other circumstances cannot be read into memory and compiled with the compile() builtin. This came up while tracking down a problem with failures using Gordan McMillan's Installer package which compiles modules using compile() before including them in the archive. I believe this is true for all releases since at least 1.5.2. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 19:35 Message: Logged In: YES user_id=6380 Hm, adding it to builtin_compile isn't enough. We'd have to add it to exec as well. I think the lexer and/or parser should take care of this -- just as it should take care of accepting \r as well as \n as well as \r\n. Yes, it's hard to find. But there's got to be a way. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 18:14 Message: Logged In: YES user_id=35752 I'm +1 on builtin_compile adding the newline. It's the lazy way out and it's better than every person hacking with the parser stumbling into it and coming up with their own work around. Guido? ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2002-03-22 18:06 Message: Logged In: YES user_id=53196 If compile() is being used in exec mode with a non- terminated multi-line string, it's not going to work unless the application generates that copy itself in any event. So without an interpreter fix, I'd think the string copy is inevitable, and it might simplify things to have the builtin function take care of it. It's something easy to overlook at the application level and could thus be fixed in one place rather than at each point of use. On the other hand, I also noticed something I overlooked when first encountering the problem - the 2.2 docs added some text to compile() talking about this need for termination. So it could be argued that it's now a documented restriction, and should the newline append (with any requisite string duplication) be needed, it leaves it to the individual applications rather than forcing it in the builtin. Not to mention a documentation solution could thus be declared already done. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-22 18:01 Message: Logged In: YES user_id=31435 Well, the user can't append an '\n' inplace either. The question is whether we do that for them, or let it blow up. OTOH, codeop.py has a lot of fun now trying to compile as-is, tben with one '\n' tacked on, then with two of 'em. It would take me a long time to figure out exactly why it's doing all that, and to guess exactly how it would break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 17:46 Message: Logged In: YES user_id=6380 Probably, unless the start symbol is "expr" (which doesn't need a newline). But it would mean copying a potentially huge string -- we can't append the \n in place. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-22 17:41 Message: Logged In: YES user_id=31435 Would it make sense for builtin_compile() to append a newline itself (say, if one weren't already present)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 17:20 Message: Logged In: YES user_id=6380 > the tok_nextc code is hairy and whatever > I tried broke something else. That's exactly what happened to me when I tried to fix this myself long ago. :-( The workaround is simple enough: whoever calls compile() should append a newline to the string just to be sure. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 17:07 Message: Logged In: YES user_id=35752 I ran into this bug myself when writing the PTL compiler. Here's a test case: code = "def foo():\n pass" open("bug.py", "w").write(code) import bug # works compile(code, "", "exec") # doesn't work I traced this bug to tok_nextc. If the input is coming from a file and the last bit of input doesn't end with a newline then one is faked. This doesn't happen if the input is coming from a string. I spent time trying to figure out how to fix it but the tok_nextc code is hairy and whatever I tried broke something else. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 17:07 Message: Logged In: YES user_id=35752 I ran into this bug myself when writing the PTL compiler. Here's a test case: code = "def foo():\n pass" open("bug.py", "w").write(code) import bug # works compile(code, "", "exec") # doesn't work I traced this bug to tok_nextc. If the input is coming from a file and the last bit of input doesn't end with a newline then one is faked. This doesn't happen if the input is coming from a string. I spent time trying to figure out how to fix it but the tok_nextc code is hairy and whatever I tried broke something else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470 From noreply@sourceforge.net Thu Nov 14 16:42:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 08:42:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-501622 ] Missing trailing newline should not raise SyntaxError Message-ID: Bugs item #501622, was opened at 2002-01-09 23:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bolen (db3l) Assigned to: Guido van Rossum (gvanrossum) >Summary: Missing trailing newline should not raise SyntaxError Initial Comment: If you have a module that you wish to compile using the builtin compile() function (in 'exec' mode), it will fail with a SyntaxError if that module does not have a newline as its final token. The same module can be executed directly by the interpreter, or imported by another module, and Python can properly compile and save a pyc for the module. I believe the difference is rooted in the fact that the tokenizer (tokenizer.c, in tok_nextc()) will "fake" a newline at the end of a file if it doesn't find one, but it will not do so when tokenizing a string buffer. What I'm not certain of is whether faking such a token for strings as well won't break something else (such as when parsing a string for an expression rather than a full module). But without such a change, you have a state where a module that works (and compiles) in other circumstances cannot be read into memory and compiled with the compile() builtin. This came up while tracking down a problem with failures using Gordan McMillan's Installer package which compiles modules using compile() before including them in the archive. I believe this is true for all releases since at least 1.5.2. -- David ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 19:35 Message: Logged In: YES user_id=6380 Hm, adding it to builtin_compile isn't enough. We'd have to add it to exec as well. I think the lexer and/or parser should take care of this -- just as it should take care of accepting \r as well as \n as well as \r\n. Yes, it's hard to find. But there's got to be a way. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 18:14 Message: Logged In: YES user_id=35752 I'm +1 on builtin_compile adding the newline. It's the lazy way out and it's better than every person hacking with the parser stumbling into it and coming up with their own work around. Guido? ---------------------------------------------------------------------- Comment By: David Bolen (db3l) Date: 2002-03-22 18:06 Message: Logged In: YES user_id=53196 If compile() is being used in exec mode with a non- terminated multi-line string, it's not going to work unless the application generates that copy itself in any event. So without an interpreter fix, I'd think the string copy is inevitable, and it might simplify things to have the builtin function take care of it. It's something easy to overlook at the application level and could thus be fixed in one place rather than at each point of use. On the other hand, I also noticed something I overlooked when first encountering the problem - the 2.2 docs added some text to compile() talking about this need for termination. So it could be argued that it's now a documented restriction, and should the newline append (with any requisite string duplication) be needed, it leaves it to the individual applications rather than forcing it in the builtin. Not to mention a documentation solution could thus be declared already done. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-22 18:01 Message: Logged In: YES user_id=31435 Well, the user can't append an '\n' inplace either. The question is whether we do that for them, or let it blow up. OTOH, codeop.py has a lot of fun now trying to compile as-is, tben with one '\n' tacked on, then with two of 'em. It would take me a long time to figure out exactly why it's doing all that, and to guess exactly how it would break. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 17:46 Message: Logged In: YES user_id=6380 Probably, unless the start symbol is "expr" (which doesn't need a newline). But it would mean copying a potentially huge string -- we can't append the \n in place. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-22 17:41 Message: Logged In: YES user_id=31435 Would it make sense for builtin_compile() to append a newline itself (say, if one weren't already present)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 17:20 Message: Logged In: YES user_id=6380 > the tok_nextc code is hairy and whatever > I tried broke something else. That's exactly what happened to me when I tried to fix this myself long ago. :-( The workaround is simple enough: whoever calls compile() should append a newline to the string just to be sure. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 17:07 Message: Logged In: YES user_id=35752 I ran into this bug myself when writing the PTL compiler. Here's a test case: code = "def foo():\n pass" open("bug.py", "w").write(code) import bug # works compile(code, "", "exec") # doesn't work I traced this bug to tok_nextc. If the input is coming from a file and the last bit of input doesn't end with a newline then one is faked. This doesn't happen if the input is coming from a string. I spent time trying to figure out how to fix it but the tok_nextc code is hairy and whatever I tried broke something else. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-22 17:07 Message: Logged In: YES user_id=35752 I ran into this bug myself when writing the PTL compiler. Here's a test case: code = "def foo():\n pass" open("bug.py", "w").write(code) import bug # works compile(code, "", "exec") # doesn't work I traced this bug to tok_nextc. If the input is coming from a file and the last bit of input doesn't end with a newline then one is faked. This doesn't happen if the input is coming from a string. I spent time trying to figure out how to fix it but the tok_nextc code is hairy and whatever I tried broke something else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470 From noreply@sourceforge.net Thu Nov 14 16:46:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 08:46:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-614555 ] Rewrite _reduce and _reconstructor in C Message-ID: Bugs item #614555, was opened at 2002-09-25 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614555&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Rewrite _reduce and _reconstructor in C Initial Comment: The copy_reg defines two functions, _reduce() and _reconstructor(), that are used for the pickling and unpickling of new-style classes. These were originally written in Python because the right implementation wasn't entirely clear; _reduce() is actually called from a C-level __reduce__ method defined in 'object', and it references _reconstructor() in its return tuple. It is now time to move both back into C for efficiency. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 11:46 Message: Logged In: YES user_id=6380 I'd like to add some comments from Jim Fulton on this (or a related) issue so they don't get lost. """ I still need to think of a good way to handle this. Currently, the pattern is a reduce return value of the form: reconstructor, (some_class, object, None), some_state but there is a more general case where an uninitialized object can be gotten by calling "type.__new__(some_class)", or even: "some_class.__new__(some_class)". There are really two issues: - It's too hard to write __reduce__ functions for this case, and - Too much data needs to be stored in pickles. A new pickling code would handler the later, but I also want to solve the former problem. One thought is to return: (copy_reg.new, (some_class, ), some_state) where copy_reg.new is: def new(class_): return class.__new__(class_) The pickler could easily spot reduce returns with copy_reg.new as the first value and generate a special pickle code. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614555&group_id=5470 From noreply@sourceforge.net Thu Nov 14 16:51:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 08:51:12 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-520382 ] Update Shelve to be more dictionary like Message-ID: Feature Requests item #520382, was opened at 2002-02-20 03:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Update Shelve to be more dictionary like Initial Comment: It's great to be able to add persistence by replacing a dictionary declaration with a shelf; however, it is not as substitutable as it could be. Most importantly, we should add __iter__ so that 'for k in d' works for shelves as well as dictionaries. Also add .items .iteritems .iterkeys .itervalues .popitem . setdefault .update and .values These methods could be added to increase substitutability without affecting existing code. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-14 11:51 Message: Logged In: YES user_id=31435 Marked Accepted since Guido approved. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 07:58 Message: Logged In: YES user_id=6380 Please go ahead. I'll apply my minor quibbles once it's in CVS. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-14 01:44 Message: Logged In: YES user_id=80475 Yes. DictMixin moved to UserDict. Yes. has_key() now uses try/except (much better). Yes. __contains__ aliased to has_key Added news item and docs. See new patch below. If the design is acceptable, I'll move on to writing the unittests. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-13 23:12 Message: Logged In: YES user_id=6380 What's py-dev? I don't recall a discussion on DictMixin on python-dev, so is it something different, maybe IRC? Maybe DIctMixin can live in UserDict? has_key() should not call keys(); it should try self[key] and catch the KeyError. __contains__ should just be an alias for has_key rather than a wrapper. But those are all details; I like the ideas here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-13 21:29 Message: Logged In: YES user_id=80475 Here is a concept sketch patch for expanding the shelve interface. The goal is to make it is easier to add persistence when an application was already developed using dictionaries as a base. On a separate note, DictMixin is offered as a stand-alone class to make it easier to create classes with a full dictionary interface. On py-dev, we concluded that DictMixin did not warrant its own module, so this would be a good place to expose the mixin class as an experimental feature while taking care of shelve at the same time. If the concept sketch appeals to you, I'll add docs, unittests, and a news item. DictMixin would be listed as experimental and potentially would not be visible in future versions of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=520382&group_id=5470 From noreply@sourceforge.net Thu Nov 14 18:28:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 10:28:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-14 19:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 00:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 22:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 20:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 21:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 18:31:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 10:31:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 18:41:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 10:41:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-484715 ] Upgrade TCL for windows installer Message-ID: Bugs item #484715, was opened at 2001-11-22 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484715&group_id=5470 Category: Windows Group: Feature Request Status: Open Resolution: Postponed Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Tim Peters (tim_one) Summary: Upgrade TCL for windows installer Initial Comment: Windows installer comes with TCL/TK 8.3.2. The latest version of TCL/TK is 8.3.4. One of the "greatest" features of the latest TCL/TK is the ability to change window icons. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-14 13:41 Message: Logged In: YES user_id=31435 As the OP said, 8.3.2 I believe Tcl/Tk is on 8.4.1 now. 8.3.2 was the last version for which we could get an unencumbered binary distribution, so we'll have to get into the Tcl/Tk compilation business too if we ever want a version newer than 8.3.2. Asking for it doesn't make it happen . ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:31 Message: Logged In: YES user_id=33168 Tim, what version of Tcl/Tk is used on Windows now? Can this be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 15:49 Message: Logged In: YES user_id=31435 This isn't "a bug", but it might be a feature request. Alas, I can't make time to do anything about it, and it's too late for 2.2 regardless. Setting to Postponed until after 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484715&group_id=5470 From noreply@sourceforge.net Thu Nov 14 18:53:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 10:53:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-14 19:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 00:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 22:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 20:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 21:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 18:56:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 10:56:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:01:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:01:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:11:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:11:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:11 Message: Logged In: YES user_id=33168 Hmmm, I have an outstanding change to PEP 291 to remove modulefinder. Is there a requirement or does the PEP need to be updated? How's the following addition to the PEP. I put it as the last para in the Rationale section. Even if a package or module is listed in this PEP, authors should document a compatibility requirement in each file with a comment at the top of the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:18:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:18:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-14 20:18 Message: Logged In: YES user_id=11105 Guido: We had some discussion about this when neal wrote the pep, and I suggested to list modulefinder there. Neal finally wrote the requirement into the PEP, and it was my impression that you accepted it, although you were not very happy with it. I will insert a comment into modulefinder.py listing the requirement. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 20:11 Message: Logged In: YES user_id=33168 Hmmm, I have an outstanding change to PEP 291 to remove modulefinder. Is there a requirement or does the PEP need to be updated? How's the following addition to the PEP. I put it as the last para in the Rationale section. Even if a package or module is listed in this PEP, authors should document a compatibility requirement in each file with a comment at the top of the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 20:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 00:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 22:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 20:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 21:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:25:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:25:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-14 20:25 Message: Logged In: YES user_id=11105 Neal: In this case (remove modulefinder from PEP 291) I won't insist on it. Let the BDFL decide, or has he already? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 20:18 Message: Logged In: YES user_id=11105 Guido: We had some discussion about this when neal wrote the pep, and I suggested to list modulefinder there. Neal finally wrote the requirement into the PEP, and it was my impression that you accepted it, although you were not very happy with it. I will insert a comment into modulefinder.py listing the requirement. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 20:11 Message: Logged In: YES user_id=33168 Hmmm, I have an outstanding change to PEP 291 to remove modulefinder. Is there a requirement or does the PEP need to be updated? How's the following addition to the PEP. I put it as the last para in the Rationale section. Even if a package or module is listed in this PEP, authors should document a compatibility requirement in each file with a comment at the top of the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 20:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 00:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 22:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 20:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 21:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:26:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:26:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 14:26 Message: Logged In: YES user_id=6380 That still doesn't explain to me *why* you wanted modulefinder.py listed. (Maybe my memory is bad.) If you were the source of that request and you're now revising the request, please go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 14:25 Message: Logged In: YES user_id=11105 Neal: In this case (remove modulefinder from PEP 291) I won't insist on it. Let the BDFL decide, or has he already? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 14:18 Message: Logged In: YES user_id=11105 Guido: We had some discussion about this when neal wrote the pep, and I suggested to list modulefinder there. Neal finally wrote the requirement into the PEP, and it was my impression that you accepted it, although you were not very happy with it. I will insert a comment into modulefinder.py listing the requirement. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:11 Message: Logged In: YES user_id=33168 Hmmm, I have an outstanding change to PEP 291 to remove modulefinder. Is there a requirement or does the PEP need to be updated? How's the following addition to the PEP. I put it as the last para in the Rationale section. Even if a package or module is listed in this PEP, authors should document a compatibility requirement in each file with a comment at the top of the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:28:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:28:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 14:28 Message: Logged In: YES user_id=6380 I have no need for modulefinder so I'm not deciding anything. It's up to Thomas. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 14:26 Message: Logged In: YES user_id=6380 That still doesn't explain to me *why* you wanted modulefinder.py listed. (Maybe my memory is bad.) If you were the source of that request and you're now revising the request, please go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 14:25 Message: Logged In: YES user_id=11105 Neal: In this case (remove modulefinder from PEP 291) I won't insist on it. Let the BDFL decide, or has he already? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 14:18 Message: Logged In: YES user_id=11105 Guido: We had some discussion about this when neal wrote the pep, and I suggested to list modulefinder there. Neal finally wrote the requirement into the PEP, and it was my impression that you accepted it, although you were not very happy with it. I will insert a comment into modulefinder.py listing the requirement. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:11 Message: Logged In: YES user_id=33168 Hmmm, I have an outstanding change to PEP 291 to remove modulefinder. Is there a requirement or does the PEP need to be updated? How's the following addition to the PEP. I put it as the last para in the Rationale section. Even if a package or module is listed in this PEP, authors should document a compatibility requirement in each file with a comment at the top of the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 14:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 13:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 13:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-12 18:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:30:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:30:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-638595 ] Move bdist_wininst source code into PC Message-ID: Bugs item #638595, was opened at 2002-11-14 14:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638595&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Thomas Heller (theller) Summary: Move bdist_wininst source code into PC Initial Comment: Please move the source code for the binary that's used by bdist_wininst into the distributed source subtree, preferably into the PC directory. (Per python-dev.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638595&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:43:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:43:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neal Norwitz (nnorwitz) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-11-14 20:43 Message: Logged In: YES user_id=11105 Yes, I requested to include modulefinder in PEP 291. There's no need to discuss this again, but I'll try to summarize the discussion we had in June: I use modulefinder in py2exe, a freeze like tool. Py2exe (currently) supports all python versions from 1.5.2 up to 2.2. Modulefinder is distributed together with py2exe, since it is not easily accessible in the Tools directory. So I requested it to be compatible with all these Python versions, but you doubted it would work because of byte-code changes. My experience is that it works well. Another approach would have been to move modulefinder into the standard lib, but you didn't want this because it is only useful for the freeze utility. So it finally ended up been listed in the pep, with me as the maintainer. Neal: I'll think about the Python versions which I want to be supported, and contact you again (or update the pep myself). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 20:28 Message: Logged In: YES user_id=6380 I have no need for modulefinder so I'm not deciding anything. It's up to Thomas. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 20:26 Message: Logged In: YES user_id=6380 That still doesn't explain to me *why* you wanted modulefinder.py listed. (Maybe my memory is bad.) If you were the source of that request and you're now revising the request, please go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 20:25 Message: Logged In: YES user_id=11105 Neal: In this case (remove modulefinder from PEP 291) I won't insist on it. Let the BDFL decide, or has he already? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 20:18 Message: Logged In: YES user_id=11105 Guido: We had some discussion about this when neal wrote the pep, and I suggested to list modulefinder there. Neal finally wrote the requirement into the PEP, and it was my impression that you accepted it, although you were not very happy with it. I will insert a comment into modulefinder.py listing the requirement. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 20:11 Message: Logged In: YES user_id=33168 Hmmm, I have an outstanding change to PEP 291 to remove modulefinder. Is there a requirement or does the PEP need to be updated? How's the following addition to the PEP. I put it as the last para in the Rationale section. Even if a package or module is listed in this PEP, authors should document a compatibility requirement in each file with a comment at the top of the file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 20:01 Message: Logged In: YES user_id=33168 I can update the PEP if you want, or you can do it yourself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:56 Message: Logged In: YES user_id=6380 I don't remenber whence the 1.5.2 requirement comes. I propose that all such requirements should be documented in a COMMENT at the TOP OF THE FILE, not just in PEP 291. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:53 Message: Logged In: YES user_id=11105 I like the first way better. Re the string methods: I'm getting tired fixing these, so I'd like to suggest to raise the PEP 291 version requirement for modulefinder to 2.0 (or 2.2?). What should I do? Contact the author (Neal, in this case)? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 19:31 Message: Logged In: YES user_id=6380 try: f = open(filename, "U") except IOError: f = open(filename, "r") You can also check for sys.version >= "2.3" ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-11-14 19:28 Message: Logged In: YES user_id=11105 Modulefinder is listed in PEP 0291 as being required to stay compatible with Python 1.5.2. A string method has crept in in line 167 which is easy to remove. Not so easy is this change for universal newline support. Since I am also listed as the maintainer, I would like to fix this. So, any idea how to detect if the current Python has universal newline support? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-13 00:21 Message: Logged In: YES user_id=33168 I don't know if there's an easy way to fix this for 2.2.x, so I'm fixing this for 2.3 with universal newlines. Checked in as: * Tools/freeze/modulefinder.py 1.22 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 22:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 20:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 21:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:50:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:50:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-618704 ] Use C3 MRO algorithm Message-ID: Bugs item #618704, was opened at 2002-10-04 15:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618704&group_id=5470 Category: Type/class unification Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Use C3 MRO algorithm Initial Comment: In http://mail.python.org/pipermail/python-dev/2002-October/029035.html and following messages, Samuele Pedroni argues that the current MRO algorithm has some unexpected properties, and that the "naive" algorithm described in the docs (keep the last occurrence in a depth-first search) is not monotonic. The current algorithm is monotonic. A better algorithm, named C3, is described in this paper: http://www.webcom.com/haahr/dylan/linearization-oopsla96.html I believe that the current algorithm is the same as L*[LOOPS] mentioned in this paper (though I have no proof). The paper argues convincingly that C3 is better than L*[LOOPS], so I propose to use C3 starting in Python 2.3. This can cause backwards compatibilities in certain cases, but the new algorithm matches intuition better than the current algorithm. (The naive algorithm from the docs is unacceptable due to its non-monotonicity.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 14:50 Message: Logged In: YES user_id=6380 Fixed; I checked in the code from patch 619475. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618704&group_id=5470 From noreply@sourceforge.net Thu Nov 14 19:53:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 11:53:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-638610 ] Instantiation init-less class with param Message-ID: Bugs item #638610, was opened at 2002-11-14 11:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638610&group_id=5470 Category: Type/class unification Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Shalabh Chaturvedi (shalabh) Assigned to: Nobody/Anonymous (nobody) Summary: Instantiation init-less class with param Initial Comment: Instantiation new style __init__-less class with parameters does not raise exception. Old style classes raise TypeError: this constructor takes no arguments. Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 >>> class C: ... pass ... >>> c = C('extra', 'params') Traceback (most recent call last): File "", line 1, in ? TypeError: this constructor takes no arguments >>> >>> class C(object): ... pass ... >>> c = C('whos','eating','my', 'params') >>> c <__main__.C object at 0x007A49B8> >>> Who? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638610&group_id=5470 From noreply@sourceforge.net Thu Nov 14 22:03:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 14:03:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-620243 ] HTMLParser:endtag events in comments Message-ID: Bugs item #620243, was opened at 2002-10-08 10:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620243&group_id=5470 Category: Python Library >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser:endtag events in comments Initial Comment: HTMLParser triggers events when met closing tags in comments. >>> from HTMLParser import HTMLParser >>> class P(HTMLParser): def handle_endtag(self,tag): print "ENDTAG",tag >>> p=P() >>> p.feed("""\ """) ENDTAG h1 ENDTAG script ENDTAG body ENDTAG html see http://groups.google.com/groups? selm=evkjmuohcuosh0tqgn2li03kfo7qknatsp% 404ax.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620243&group_id=5470 From noreply@sourceforge.net Thu Nov 14 22:15:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 14:15:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-638703 ] optparse not documented Message-ID: Bugs item #638703, was opened at 2002-11-14 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: optparse not documented Initial Comment: Some volunteer needs to document the optparse module. The text files from optik may supply a good source for material for the LaTeX version of the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 From noreply@sourceforge.net Thu Nov 14 22:15:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 14:15:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-638703 ] optparse module undocumented Message-ID: Bugs item #638703, was opened at 2002-11-14 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Nobody/Anonymous (nobody) >Summary: optparse module undocumented Initial Comment: Some volunteer needs to document the optparse module. The text files from optik may supply a good source for material for the LaTeX version of the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 From noreply@sourceforge.net Thu Nov 14 22:50:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 14:50:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-624024 ] Broken link in local documentation. Message-ID: Bugs item #624024, was opened at 2002-10-16 06:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624024&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Victor V. Kryukov (vtail) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Broken link in local documentation. Initial Comment: Hi. Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 In my python local documentation, link 'Up: Python Documentation Index' in 'Global Module Index' leads to './' instead off '../index.html'. I suppose this is a bug. Thanks, Victor. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-14 17:50 Message: Logged In: YES user_id=3066 Fixed in Doc/tools/support.py revision 1.4.8.1. The trunk does not need this change since it already does the right thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624024&group_id=5470 From noreply@sourceforge.net Thu Nov 14 23:10:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 15:10:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-633504 ] cgi.py drops commandline arguments Message-ID: Bugs item #633504, was opened at 2002-11-04 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633504&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Randall Randall (randallrandall) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py drops commandline arguments Initial Comment: Keyword arguments in URLs are currently ignored by the cgi.parse_qsl() function, even though they are explicitly included by cgi.parse(), i.e.: 
...
    elif sys.argv[1:]:
        if qs: qs = qs + '&'
        qs = qs + sys.argv[1]
...
A simple patch to fix this follows: 
216c216
<             continue
---
>             else: nv.append('')
This fix doesn't affect those using strictparsing=1 , which will still fail to include anything without an equals ('='). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:10 Message: Logged In: YES user_id=6380 I'd be willing to have this fixed, if I could understand the problem. Can you show an example program and how it does not do what you expect? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633504&group_id=5470 From noreply@sourceforge.net Thu Nov 14 23:13:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 15:13:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-633930 ] Nested class __name__ Message-ID: Bugs item #633930, was opened at 2002-11-05 12:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Nested class __name__ Initial Comment: The __name__ attribute of a nested class should be set to 'outer.inner', both for classic and for new-style classes. E.g. >>> class C: ... class C1: pass ... >>> C.C1.__name__ 'C.C1' >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:13 Message: Logged In: YES user_id=6380 Hm, but should this also be done for functions inside classes? E.g. class C: def foo(self): pass assert C.foo.__name__ == "C.foo" assert C.__dict__["foo"].__name__ == "C.foo" And what about classes inside functions? def f(): class C: pass return C assert f().__name__ == "f.C" ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 From noreply@sourceforge.net Thu Nov 14 23:22:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 15:22:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-635115 ] int(1e200) should return long Message-ID: Bugs item #635115, was opened at 2002-11-07 14:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635115&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: int(1e200) should return long Initial Comment: To remove the distinction between int and long int(1e200) should return a long object instead of raising an OverflowError. This is related to bug #629989: int("123123123123123123") doesn't work. Fixing this could be done by changing Objects/floatobject.c/float_int (see attached patch), but this changes the meaning of the nb_int slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:22 Message: Logged In: YES user_id=6380 PyInt_AsLong() insists that nb_int returns a PyInt_Object. I think it's okay that nb_int returns a non-int -- classes don't require __int__ to do this either. So PyInt_AsLong() should accept a PyLong_Object as well, I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635115&group_id=5470 From noreply@sourceforge.net Thu Nov 14 23:23:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 15:23:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-635929 ] 2.2.2 build on Solaris Message-ID: Bugs item #635929, was opened at 2002-11-09 09:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635929&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2.2 build on Solaris Initial Comment: Attached is a message that concludes an exchange between David LeVine and me. He built Python using the gcc 3.2 from sunfreeware.com. Running ./python, he got this error: ld.so.1: ./python: fatal: libstdc++.so.5: open failed: No such file or directory I suggested adding a -R somewhere and he got it to work by patching configure. Perhaps a real fix can be made out of this? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:23 Message: Logged In: YES user_id=6380 Feel free to close it then. It seemed obscure to me at best. Maybe a note can be added to README with the solution? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-09 13:02 Message: Logged In: YES user_id=21627 I'm not sure that this should be fixed in Python, there are several complications: 1. It is not certain that python is linked with libstdc++. If not, you only need to worry about libgcc_s.so, if gcc is gcc 3.2. 2. It is not certain whether /usr/local is the right prefix; gcc might be installed with a different prefix. 3. It is not certain whether libstdc++ is installed in /lib, gcc also supports installing it into /lib/gcc-lib// 4. Randomly adding -R options might shoot back, since python may now pick up the wrong libraries, for libraries used in extension modules. We usually fix this in the gcc installation, not in all affected applications, by adding proper -R options into the installed specs file. I would rather "fix" this by pointing out that gcc 3 users will have to set LD_RUN_PATH on Solaris, to include the directories containing libgcc_s.so.1, and possibly libstdc++.so.xy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635929&group_id=5470 From noreply@sourceforge.net Thu Nov 14 23:26:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 15:26:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-638610 ] Instantiation init-less class with param Message-ID: Bugs item #638610, was opened at 2002-11-14 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638610&group_id=5470 Category: Type/class unification Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Shalabh Chaturvedi (shalabh) Assigned to: Nobody/Anonymous (nobody) Summary: Instantiation init-less class with param Initial Comment: Instantiation new style __init__-less class with parameters does not raise exception. Old style classes raise TypeError: this constructor takes no arguments. Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 >>> class C: ... pass ... >>> c = C('extra', 'params') Traceback (most recent call last): File "", line 1, in ? TypeError: this constructor takes no arguments >>> >>> class C(object): ... pass ... >>> c = C('whos','eating','my', 'params') >>> c <__main__.C object at 0x007A49B8> >>> Who? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 18:26 Message: Logged In: YES user_id=33168 Confirmed the behaviour in 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638610&group_id=5470 From noreply@sourceforge.net Thu Nov 14 23:33:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 15:33:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-484715 ] Upgrade TCL for windows installer Message-ID: Bugs item #484715, was opened at 2001-11-22 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484715&group_id=5470 Category: Windows Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Tim Peters (tim_one) Summary: Upgrade TCL for windows installer Initial Comment: Windows installer comes with TCL/TK 8.3.2. The latest version of TCL/TK is 8.3.4. One of the "greatest" features of the latest TCL/TK is the ability to change window icons. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-11-14 18:33 Message: Logged In: YES user_id=31435 Python 2.3 will ship with Tcl/Tk 8.4.1 on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-14 13:41 Message: Logged In: YES user_id=31435 As the OP said, 8.3.2 I believe Tcl/Tk is on 8.4.1 now. 8.3.2 was the last version for which we could get an unencumbered binary distribution, so we'll have to get into the Tcl/Tk compilation business too if we ever want a version newer than 8.3.2. Asking for it doesn't make it happen . ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 21:31 Message: Logged In: YES user_id=33168 Tim, what version of Tcl/Tk is used on Windows now? Can this be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-27 15:49 Message: Logged In: YES user_id=31435 This isn't "a bug", but it might be a feature request. Alas, I can't make time to do anything about it, and it's too late for 2.2 regardless. Setting to Postponed until after 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484715&group_id=5470 From noreply@sourceforge.net Fri Nov 15 05:21:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Nov 2002 21:21:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-620243 ] HTMLParser:endtag events in comments Message-ID: Bugs item #620243, was opened at 2002-10-08 10:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620243&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Pending Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser:endtag events in comments Initial Comment: HTMLParser triggers events when met closing tags in comments. >>> from HTMLParser import HTMLParser >>> class P(HTMLParser): def handle_endtag(self,tag): print "ENDTAG",tag >>> p=P() >>> p.feed("""\ """) ENDTAG h1 ENDTAG script ENDTAG body ENDTAG html see http://groups.google.com/groups? selm=evkjmuohcuosh0tqgn2li03kfo7qknatsp% 404ax.com ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-11-15 00:21 Message: Logged In: YES user_id=3066 I'm not convinced this is a bug, but that's mainly due to details of the specification some people consider obscure, and to (ta da!)... the version of the HTML spec you look at! Here's a quick synopsis; refer to the latest edition of the HTML 4 spec for more details. There are two kinds of character data in HTML documents, PCDATA and CDATA. Most is PCDATA, which means all markup constructs are allowed. A few elements (SCRIPT and STYLE in particular) contain the more restrictive CDATA, which allows only end elements. Since SCRIPT contains CDATA (in the more recent versions of HTML), comments are not recognized -- the characters '