From noreply@sourceforge.net Sat Mar 1 01:36:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 17:36:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-693955 ] Can't multiply str and bool Message-ID: Bugs item #693955, was opened at 2003-02-26 17:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693955&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Can't multiply str and bool Initial Comment: Bug in 2.3a2+: 'abc' * True raises a TypeError: unsupported operand type(s) for *: 'str' and 'bool' . site.py does: initial_slashes = path.startswith('/'); path = '/'*initial_slashes + path . This now fails. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 20:36 Message: Logged In: YES user_id=80475 C:\pydev>python I cannot reproduce the bug: Python 2.3a2+ (#39, Feb 28 2003, 02:20:12) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 'abc' * True 'abc' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693955&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:02:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:02:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails Message-ID: Bugs item #678217, was opened at 2003-01-31 11:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging fails Initial Comment: When I run the test suite, test_logging sometimes fails. It misses the following output and gets a bunch of exceptions llike the one I included at the end. I haven't counted, but I'd guess that there's one traceback for each missing line of output. test test_logging produced unexpected output: ********************************************************************** *** lines 489-514 of expected output missing: - ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR) - ERR -> ERROR: Message 1 (via logrecv.tcp.ERR) - INF -> CRITICAL: Message 2 (via logrecv.tcp.INF) - INF -> ERROR: Message 3 (via logrecv.tcp.INF) - INF -> WARN: Message 4 (via logrecv.tcp.INF) - INF -> INFO: Message 5 (via logrecv.tcp.INF) - INF.UNDEF -> CRITICAL: Message 6 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF) - INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR) - INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR) - INF.ERR.UNDEF -> CRITICAL: Message 12 (via logrecv.tcp.INF.ERR.UNDEF) - INF.ERR.UNDEF -> ERROR: Message 13 (via logrecv.tcp.INF.ERR.UNDEF) - DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB) - DEB -> ERROR: Message 15 (via logrecv.tcp.DEB) - DEB -> WARN: Message 16 (via logrecv.tcp.DEB) - DEB -> INFO: Message 17 (via logrecv.tcp.DEB) - DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB) - UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF) - UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF) - UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF) - UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF) - INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via logrecv.tcp.INF.BADPARENT.UNDEF) - INF.BADPARENT -> CRITICAL: Message 24 (via logrecv.tcp.INF.BADPARENT) - INF -> INFO: Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ********************************************************************** Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:02 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:08:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:08:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-693121 ] Set == non-Set is a TypeError Message-ID: Bugs item #693121, was opened at 2003-02-25 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Reedy (creedy) Assigned to: Nobody/Anonymous (nobody) Summary: Set == non-Set is a TypeError Initial Comment: Comparing Sets to non-Sets results in a TypeError. For example: >>> from sets import Set >>> x = Set([1]) >>> x == 2 TypeError: Binary operation only permitted between sets This seems to be inconsistent with other Python behavior. For example: >>> (1,2,3) == 2 0 >>> "abcd" == 2 0 Assuming that the standard behavior is what is desired, the implementation of __eq__ and other comparison operators in sets.py should be changed to return NotImplemented when the other object is not a Set. Note: Looking at the code, I'm not sure whether the implementation of __lt__, __le__, etc. should also be changed to not return a Type Error. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:08 Message: Logged In: YES user_id=80475 The OP added this note at the behest of comp.lang.python. The thread is at: http://tinyurl.com/6n91 and includes some comments by Tim. Assigning to Guido to decide whether he wants to keep that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:09:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:09:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-693121 ] Set == non-Set is a TypeError Message-ID: Bugs item #693121, was opened at 2003-02-25 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Reedy (creedy) >Assigned to: Guido van Rossum (gvanrossum) Summary: Set == non-Set is a TypeError Initial Comment: Comparing Sets to non-Sets results in a TypeError. For example: >>> from sets import Set >>> x = Set([1]) >>> x == 2 TypeError: Binary operation only permitted between sets This seems to be inconsistent with other Python behavior. For example: >>> (1,2,3) == 2 0 >>> "abcd" == 2 0 Assuming that the standard behavior is what is desired, the implementation of __eq__ and other comparison operators in sets.py should be changed to return NotImplemented when the other object is not a Set. Note: Looking at the code, I'm not sure whether the implementation of __lt__, __le__, etc. should also be changed to not return a Type Error. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:08 Message: Logged In: YES user_id=80475 The OP added this note at the behest of comp.lang.python. The thread is at: http://tinyurl.com/6n91 and includes some comments by Tim. Assigning to Guido to decide whether he wants to keep that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:10:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:10:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 15:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Neal Norwitz (nnorwitz) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:10 Message: Logged In: YES user_id=6380 Neal, do you have a Windows machine to test this on? (It's for Python 2.2.3) (I'm not sure why this needs to be tested on Windows at all - maybe because of the subtle changes to cmd.py?) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-24 17:30 Message: Logged In: YES user_id=80475 Assigning to Neal because I can't test this on my Windows machine. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-21 12:52 Message: Logged In: YES user_id=670441 I'm attaching backported versions against cmd.py 1.26.16.3 readline.c 2.41.6.4 if you want them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 07:42 Message: Logged In: YES user_id=6380 Good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 02:42 Message: Logged In: YES user_id=80475 Backport? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-03 06:11 Message: Logged In: YES user_id=6656 Checked in as Lib/cmd.py revision 1.34 Thanks! You probably didn't need to attach the patch three times, though :-) ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:41 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:37 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-31 16:25 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 11:59 Message: Logged In: YES user_id=670441 That sounds good to me. Go ahead and check in patchcmd. Thanks for your suggestions, I will follow them in future patches. In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!). Okay that's definitely enough commentary for a few line patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-30 05:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 13:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 10:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 05:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:19:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:19:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 15:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) >Assigned to: Guido van Rossum (gvanrossum) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:19 Message: Logged In: YES user_id=6380 I'll just check this in -- I don't see any reason to test it on Windows. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:10 Message: Logged In: YES user_id=6380 Neal, do you have a Windows machine to test this on? (It's for Python 2.2.3) (I'm not sure why this needs to be tested on Windows at all - maybe because of the subtle changes to cmd.py?) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-24 17:30 Message: Logged In: YES user_id=80475 Assigning to Neal because I can't test this on my Windows machine. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-21 12:52 Message: Logged In: YES user_id=670441 I'm attaching backported versions against cmd.py 1.26.16.3 readline.c 2.41.6.4 if you want them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 07:42 Message: Logged In: YES user_id=6380 Good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 02:42 Message: Logged In: YES user_id=80475 Backport? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-03 06:11 Message: Logged In: YES user_id=6656 Checked in as Lib/cmd.py revision 1.34 Thanks! You probably didn't need to attach the patch three times, though :-) ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:41 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:37 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-31 16:25 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 11:59 Message: Logged In: YES user_id=670441 That sounds good to me. Go ahead and check in patchcmd. Thanks for your suggestions, I will follow them in future patches. In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!). Okay that's definitely enough commentary for a few line patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-30 05:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 13:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 10:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 05:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:23:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:23:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-693955 ] Can't multiply str and bool Message-ID: Bugs item #693955, was opened at 2003-02-26 17:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693955&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: Can't multiply str and bool Initial Comment: Bug in 2.3a2+: 'abc' * True raises a TypeError: unsupported operand type(s) for *: 'str' and 'bool' . site.py does: initial_slashes = path.startswith('/'); path = '/'*initial_slashes + path . This now fails. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-02-28 21:23 Message: Logged In: YES user_id=11375 Hm... puzzling. I'll try to replicate it tomorrow, and will close the bug if I can't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 20:36 Message: Logged In: YES user_id=80475 C:\pydev>python I cannot reproduce the bug: Python 2.3a2+ (#39, Feb 28 2003, 02:20:12) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 'abc' * True 'abc' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693955&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:23:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:23:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-690389 ] register command not listed in command line help Message-ID: Bugs item #690389, was opened at 2003-02-20 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690389&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 2 Submitted By: Stuart Bishop (zenzen) >Assigned to: A.M. Kuchling (akuchling) Summary: register command not listed in command line help Initial Comment: The register command is not listed when you run python setup.py --help-commands ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690389&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:24:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:24:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-693470 ] licence allowed, but doesn't work Message-ID: Bugs item #693470, was opened at 2003-02-26 02:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693470&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: A.M. Kuchling (akuchling) Summary: licence allowed, but doesn't work Initial Comment: 'licence' is accepted without warning as a keyword argument to setup(), but it doesn't actually work. Spelling it 'license' works as expected. Looks like an attempt to accept common misspellings failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693470&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:24:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:24:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 15:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:24 Message: Logged In: YES user_id=6380 OK, fixed. Who cares if this works on Windows. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:19 Message: Logged In: YES user_id=6380 I'll just check this in -- I don't see any reason to test it on Windows. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:10 Message: Logged In: YES user_id=6380 Neal, do you have a Windows machine to test this on? (It's for Python 2.2.3) (I'm not sure why this needs to be tested on Windows at all - maybe because of the subtle changes to cmd.py?) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-24 17:30 Message: Logged In: YES user_id=80475 Assigning to Neal because I can't test this on my Windows machine. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-21 12:52 Message: Logged In: YES user_id=670441 I'm attaching backported versions against cmd.py 1.26.16.3 readline.c 2.41.6.4 if you want them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 07:42 Message: Logged In: YES user_id=6380 Good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 02:42 Message: Logged In: YES user_id=80475 Backport? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-03 06:11 Message: Logged In: YES user_id=6656 Checked in as Lib/cmd.py revision 1.34 Thanks! You probably didn't need to attach the patch three times, though :-) ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:41 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:37 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-31 16:25 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 11:59 Message: Logged In: YES user_id=670441 That sounds good to me. Go ahead and check in patchcmd. Thanks for your suggestions, I will follow them in future patches. In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!). Okay that's definitely enough commentary for a few line patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-30 05:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 13:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 10:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 05:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:29:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:29:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-690419 ] can't build bsddb for 2.3a2 Message-ID: Bugs item #690419, was opened at 2003-02-20 20:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Skip Montanaro (montanaro) Summary: can't build bsddb for 2.3a2 Initial Comment: I have db-4.1.25 installed, and I'm trying to install Python 2.3a2 with bsddb. The build fails: gcc -fPIC -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/package/misc/spf/python-2.3a2/spf/db/include -c ./Modules/bsddbmodule.c -o Modules/bsddbmodule.o Modules/bsddbmodule.c: In function `newdbhashobject': Modules/bsddbmodule.c:58: `HASHINFO' undeclared (first use in this function) Modules/bsddbmodule.c:58: (Each undeclared identifier is reported only once Modules/bsddbmodule.c:58: for each function it appears in.) Modules/bsddbmodule.c:58: parse error before "info" Modules/bsddbmodule.c:63: `info' undeclared (first use in this function) Modules/bsddbmodule.c:74: warning: implicit declaration of function `dbopen' Modules/bsddbmodule.c:74: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbbtobject': Modules/bsddbmodule.c:106: `BTREEINFO' undeclared (first use in this function) Modules/bsddbmodule.c:106: parse error before "info" Modules/bsddbmodule.c:111: `info' undeclared (first use in this function) Modules/bsddbmodule.c:124: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbrnobject': Modules/bsddbmodule.c:156: `RECNOINFO' undeclared (first use in this function) Modules/bsddbmodule.c:156: parse error before "info" Modules/bsddbmodule.c:162: `info' undeclared (first use in this function) Modules/bsddbmodule.c:182: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `bsddb_dealloc': Modules/bsddbmodule.c:223: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_length': Modules/bsddbmodule.c:252: structure has no member named `seq' Modules/bsddbmodule.c:253: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:255: structure has no member named `seq' Modules/bsddbmodule.c:256: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_subscript': Modules/bsddbmodule.c:276: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:276: parse error before "recno" Modules/bsddbmodule.c:279: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:299: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:299: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_ass_sub': Modules/bsddbmodule.c:327: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:327: parse error before "recno" Modules/bsddbmodule.c:330: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:351: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:351: too few arguments to function Modules/bsddbmodule.c:363: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:363: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_close': Modules/bsddbmodule.c:388: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_keys': Modules/bsddbmodule.c:415: structure has no member named `seq' Modules/bsddbmodule.c:415: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:441: structure has no member named `seq' Modules/bsddbmodule.c:442: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_has_key': Modules/bsddbmodule.c:470: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:470: parse error before "recno" Modules/bsddbmodule.c:474: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:491: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:491: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_set_location': Modules/bsddbmodule.c:509: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:509: parse error before "recno" Modules/bsddbmodule.c:513: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:530: structure has no member named `seq' Modules/bsddbmodule.c:530: `R_CURSOR' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_seq': Modules/bsddbmodule.c:570: structure has no member named `seq' Modules/bsddbmodule.c: In function `bsddb_next': Modules/bsddbmodule.c:608: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_previous': Modules/bsddbmodule.c:613: `R_PREV' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_first': Modules/bsddbmodule.c:618: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_last': Modules/bsddbmodule.c:623: `R_LAST' undeclared (first use in this function) make: *** [Modules/bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:29 Message: Logged In: YES user_id=6380 Seems something that Skip might understand. Looks to me like you've picked up an incompatible version of the db.h or db_185.h header file... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-02-24 12:22 Message: Logged In: YES user_id=412110 Ok, here it is as an attachment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:12 Message: Logged In: YES user_id=6380 Please don't include long listings in the bug report. Attach then separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:43:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:43:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-690419 ] can't build bsddb for 2.3a2 Message-ID: Bugs item #690419, was opened at 2003-02-20 19:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Skip Montanaro (montanaro) Summary: can't build bsddb for 2.3a2 Initial Comment: I have db-4.1.25 installed, and I'm trying to install Python 2.3a2 with bsddb. The build fails: gcc -fPIC -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/package/misc/spf/python-2.3a2/spf/db/include -c ./Modules/bsddbmodule.c -o Modules/bsddbmodule.o Modules/bsddbmodule.c: In function `newdbhashobject': Modules/bsddbmodule.c:58: `HASHINFO' undeclared (first use in this function) Modules/bsddbmodule.c:58: (Each undeclared identifier is reported only once Modules/bsddbmodule.c:58: for each function it appears in.) Modules/bsddbmodule.c:58: parse error before "info" Modules/bsddbmodule.c:63: `info' undeclared (first use in this function) Modules/bsddbmodule.c:74: warning: implicit declaration of function `dbopen' Modules/bsddbmodule.c:74: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbbtobject': Modules/bsddbmodule.c:106: `BTREEINFO' undeclared (first use in this function) Modules/bsddbmodule.c:106: parse error before "info" Modules/bsddbmodule.c:111: `info' undeclared (first use in this function) Modules/bsddbmodule.c:124: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbrnobject': Modules/bsddbmodule.c:156: `RECNOINFO' undeclared (first use in this function) Modules/bsddbmodule.c:156: parse error before "info" Modules/bsddbmodule.c:162: `info' undeclared (first use in this function) Modules/bsddbmodule.c:182: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `bsddb_dealloc': Modules/bsddbmodule.c:223: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_length': Modules/bsddbmodule.c:252: structure has no member named `seq' Modules/bsddbmodule.c:253: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:255: structure has no member named `seq' Modules/bsddbmodule.c:256: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_subscript': Modules/bsddbmodule.c:276: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:276: parse error before "recno" Modules/bsddbmodule.c:279: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:299: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:299: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_ass_sub': Modules/bsddbmodule.c:327: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:327: parse error before "recno" Modules/bsddbmodule.c:330: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:351: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:351: too few arguments to function Modules/bsddbmodule.c:363: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:363: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_close': Modules/bsddbmodule.c:388: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_keys': Modules/bsddbmodule.c:415: structure has no member named `seq' Modules/bsddbmodule.c:415: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:441: structure has no member named `seq' Modules/bsddbmodule.c:442: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_has_key': Modules/bsddbmodule.c:470: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:470: parse error before "recno" Modules/bsddbmodule.c:474: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:491: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:491: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_set_location': Modules/bsddbmodule.c:509: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:509: parse error before "recno" Modules/bsddbmodule.c:513: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:530: structure has no member named `seq' Modules/bsddbmodule.c:530: `R_CURSOR' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_seq': Modules/bsddbmodule.c:570: structure has no member named `seq' Modules/bsddbmodule.c: In function `bsddb_next': Modules/bsddbmodule.c:608: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_previous': Modules/bsddbmodule.c:613: `R_PREV' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_first': Modules/bsddbmodule.c:618: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_last': Modules/bsddbmodule.c:623: `R_LAST' undeclared (first use in this function) make: *** [Modules/bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-02-28 20:43 Message: Logged In: YES user_id=44345 I agree with Guido. HASHINFO is defined in db185.h. You are trying to compile the older bsddb (now named bsddb185) module using a version of Berkeley DB which was not configured for backward compatibility. When you built Berkeley DB itself did you run configure with the --enable-compat185 flag? If not, you won't be able to compile Modules/bsddbmodule.c. In any case, if you have db-4.x installed, don't bother with the old version of the bsddb module. The new one has a backward compatible API. You should only be building the old version if you are forced to use db-1.85 or db-2.x. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 20:29 Message: Logged In: YES user_id=6380 Seems something that Skip might understand. Looks to me like you've picked up an incompatible version of the db.h or db_185.h header file... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-02-24 11:22 Message: Logged In: YES user_id=412110 Ok, here it is as an attachment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 08:12 Message: Logged In: YES user_id=6380 Please don't include long listings in the bug report. Attach then separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:45:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:45:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-693121 ] Set == non-Set is a TypeError Message-ID: Bugs item #693121, was opened at 2003-02-25 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Reedy (creedy) Assigned to: Guido van Rossum (gvanrossum) Summary: Set == non-Set is a TypeError Initial Comment: Comparing Sets to non-Sets results in a TypeError. For example: >>> from sets import Set >>> x = Set([1]) >>> x == 2 TypeError: Binary operation only permitted between sets This seems to be inconsistent with other Python behavior. For example: >>> (1,2,3) == 2 0 >>> "abcd" == 2 0 Assuming that the standard behavior is what is desired, the implementation of __eq__ and other comparison operators in sets.py should be changed to return NotImplemented when the other object is not a Set. Note: Looking at the code, I'm not sure whether the implementation of __lt__, __le__, etc. should also be changed to not return a Type Error. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-02-28 21:45 Message: Logged In: YES user_id=31435 Short course: returning NotImplemented (== falling back to address comparison, unless the other comparand wants to handle it) instead for __eq__ and __ne__ would be fine. That would be similar to what was done for datetime objects in 2.3a2. The other 4 relationals shouldn't be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:08 Message: Logged In: YES user_id=80475 The OP added this note at the behest of comp.lang.python. The thread is at: http://tinyurl.com/6n91 and includes some comments by Tim. Assigning to Guido to decide whether he wants to keep that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:45:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:45:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-690419 ] can't build bsddb for 2.3a2 Message-ID: Bugs item #690419, was opened at 2003-02-20 20:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Paul Jarc (prjsf) Assigned to: Skip Montanaro (montanaro) Summary: can't build bsddb for 2.3a2 Initial Comment: I have db-4.1.25 installed, and I'm trying to install Python 2.3a2 with bsddb. The build fails: gcc -fPIC -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/package/misc/spf/python-2.3a2/spf/db/include -c ./Modules/bsddbmodule.c -o Modules/bsddbmodule.o Modules/bsddbmodule.c: In function `newdbhashobject': Modules/bsddbmodule.c:58: `HASHINFO' undeclared (first use in this function) Modules/bsddbmodule.c:58: (Each undeclared identifier is reported only once Modules/bsddbmodule.c:58: for each function it appears in.) Modules/bsddbmodule.c:58: parse error before "info" Modules/bsddbmodule.c:63: `info' undeclared (first use in this function) Modules/bsddbmodule.c:74: warning: implicit declaration of function `dbopen' Modules/bsddbmodule.c:74: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbbtobject': Modules/bsddbmodule.c:106: `BTREEINFO' undeclared (first use in this function) Modules/bsddbmodule.c:106: parse error before "info" Modules/bsddbmodule.c:111: `info' undeclared (first use in this function) Modules/bsddbmodule.c:124: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbrnobject': Modules/bsddbmodule.c:156: `RECNOINFO' undeclared (first use in this function) Modules/bsddbmodule.c:156: parse error before "info" Modules/bsddbmodule.c:162: `info' undeclared (first use in this function) Modules/bsddbmodule.c:182: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `bsddb_dealloc': Modules/bsddbmodule.c:223: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_length': Modules/bsddbmodule.c:252: structure has no member named `seq' Modules/bsddbmodule.c:253: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:255: structure has no member named `seq' Modules/bsddbmodule.c:256: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_subscript': Modules/bsddbmodule.c:276: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:276: parse error before "recno" Modules/bsddbmodule.c:279: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:299: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:299: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_ass_sub': Modules/bsddbmodule.c:327: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:327: parse error before "recno" Modules/bsddbmodule.c:330: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:351: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:351: too few arguments to function Modules/bsddbmodule.c:363: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:363: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_close': Modules/bsddbmodule.c:388: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_keys': Modules/bsddbmodule.c:415: structure has no member named `seq' Modules/bsddbmodule.c:415: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:441: structure has no member named `seq' Modules/bsddbmodule.c:442: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_has_key': Modules/bsddbmodule.c:470: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:470: parse error before "recno" Modules/bsddbmodule.c:474: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:491: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:491: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_set_location': Modules/bsddbmodule.c:509: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:509: parse error before "recno" Modules/bsddbmodule.c:513: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:530: structure has no member named `seq' Modules/bsddbmodule.c:530: `R_CURSOR' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_seq': Modules/bsddbmodule.c:570: structure has no member named `seq' Modules/bsddbmodule.c: In function `bsddb_next': Modules/bsddbmodule.c:608: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_previous': Modules/bsddbmodule.c:613: `R_PREV' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_first': Modules/bsddbmodule.c:618: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_last': Modules/bsddbmodule.c:623: `R_LAST' undeclared (first use in this function) make: *** [Modules/bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:45 Message: Logged In: YES user_id=6380 Isn't a problem with that advice that setup.py always tries to build bsddbmodule.c when it finds the appropriate headers? I think I've got the same problem on my system ATM. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-28 21:43 Message: Logged In: YES user_id=44345 I agree with Guido. HASHINFO is defined in db185.h. You are trying to compile the older bsddb (now named bsddb185) module using a version of Berkeley DB which was not configured for backward compatibility. When you built Berkeley DB itself did you run configure with the --enable-compat185 flag? If not, you won't be able to compile Modules/bsddbmodule.c. In any case, if you have db-4.x installed, don't bother with the old version of the bsddb module. The new one has a backward compatible API. You should only be building the old version if you are forced to use db-1.85 or db-2.x. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:29 Message: Logged In: YES user_id=6380 Seems something that Skip might understand. Looks to me like you've picked up an incompatible version of the db.h or db_185.h header file... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-02-24 12:22 Message: Logged In: YES user_id=412110 Ok, here it is as an attachment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:12 Message: Logged In: YES user_id=6380 Please don't include long listings in the bug report. Attach then separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 From noreply@sourceforge.net Sat Mar 1 02:48:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:48:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-693121 ] Set == non-Set is a TypeError Message-ID: Bugs item #693121, was opened at 2003-02-25 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Reedy (creedy) >Assigned to: Raymond Hettinger (rhettinger) Summary: Set == non-Set is a TypeError Initial Comment: Comparing Sets to non-Sets results in a TypeError. For example: >>> from sets import Set >>> x = Set([1]) >>> x == 2 TypeError: Binary operation only permitted between sets This seems to be inconsistent with other Python behavior. For example: >>> (1,2,3) == 2 0 >>> "abcd" == 2 0 Assuming that the standard behavior is what is desired, the implementation of __eq__ and other comparison operators in sets.py should be changed to return NotImplemented when the other object is not a Set. Note: Looking at the code, I'm not sure whether the implementation of __lt__, __le__, etc. should also be changed to not return a Type Error. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:48 Message: Logged In: YES user_id=6380 Yes, that's the right solution. In general, more objects should implement this behavior: __eq__, __ne__ return NotImplemented, the others continue to raise TypeError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-28 21:45 Message: Logged In: YES user_id=31435 Short course: returning NotImplemented (== falling back to address comparison, unless the other comparand wants to handle it) instead for __eq__ and __ne__ would be fine. That would be similar to what was done for datetime objects in 2.3a2. The other 4 relationals shouldn't be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:08 Message: Logged In: YES user_id=80475 The OP added this note at the behest of comp.lang.python. The thread is at: http://tinyurl.com/6n91 and includes some comments by Tim. Assigning to Guido to decide whether he wants to keep that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 From noreply@sourceforge.net Sat Mar 1 03:22:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 19:22:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-690419 ] can't build bsddb for 2.3a2 Message-ID: Bugs item #690419, was opened at 2003-02-20 20:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Paul Jarc (prjsf) Assigned to: Skip Montanaro (montanaro) Summary: can't build bsddb for 2.3a2 Initial Comment: I have db-4.1.25 installed, and I'm trying to install Python 2.3a2 with bsddb. The build fails: gcc -fPIC -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/package/misc/spf/python-2.3a2/spf/db/include -c ./Modules/bsddbmodule.c -o Modules/bsddbmodule.o Modules/bsddbmodule.c: In function `newdbhashobject': Modules/bsddbmodule.c:58: `HASHINFO' undeclared (first use in this function) Modules/bsddbmodule.c:58: (Each undeclared identifier is reported only once Modules/bsddbmodule.c:58: for each function it appears in.) Modules/bsddbmodule.c:58: parse error before "info" Modules/bsddbmodule.c:63: `info' undeclared (first use in this function) Modules/bsddbmodule.c:74: warning: implicit declaration of function `dbopen' Modules/bsddbmodule.c:74: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbbtobject': Modules/bsddbmodule.c:106: `BTREEINFO' undeclared (first use in this function) Modules/bsddbmodule.c:106: parse error before "info" Modules/bsddbmodule.c:111: `info' undeclared (first use in this function) Modules/bsddbmodule.c:124: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbrnobject': Modules/bsddbmodule.c:156: `RECNOINFO' undeclared (first use in this function) Modules/bsddbmodule.c:156: parse error before "info" Modules/bsddbmodule.c:162: `info' undeclared (first use in this function) Modules/bsddbmodule.c:182: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `bsddb_dealloc': Modules/bsddbmodule.c:223: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_length': Modules/bsddbmodule.c:252: structure has no member named `seq' Modules/bsddbmodule.c:253: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:255: structure has no member named `seq' Modules/bsddbmodule.c:256: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_subscript': Modules/bsddbmodule.c:276: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:276: parse error before "recno" Modules/bsddbmodule.c:279: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:299: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:299: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_ass_sub': Modules/bsddbmodule.c:327: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:327: parse error before "recno" Modules/bsddbmodule.c:330: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:351: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:351: too few arguments to function Modules/bsddbmodule.c:363: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:363: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_close': Modules/bsddbmodule.c:388: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_keys': Modules/bsddbmodule.c:415: structure has no member named `seq' Modules/bsddbmodule.c:415: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:441: structure has no member named `seq' Modules/bsddbmodule.c:442: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_has_key': Modules/bsddbmodule.c:470: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:470: parse error before "recno" Modules/bsddbmodule.c:474: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:491: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:491: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_set_location': Modules/bsddbmodule.c:509: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:509: parse error before "recno" Modules/bsddbmodule.c:513: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:530: structure has no member named `seq' Modules/bsddbmodule.c:530: `R_CURSOR' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_seq': Modules/bsddbmodule.c:570: structure has no member named `seq' Modules/bsddbmodule.c: In function `bsddb_next': Modules/bsddbmodule.c:608: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_previous': Modules/bsddbmodule.c:613: `R_PREV' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_first': Modules/bsddbmodule.c:618: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_last': Modules/bsddbmodule.c:623: `R_LAST' undeclared (first use in this function) make: *** [Modules/bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 22:22 Message: Logged In: YES user_id=6380 (Um, I've got that problem alright, but it's on the Python 2.2.x branch... So ignore that.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:45 Message: Logged In: YES user_id=6380 Isn't a problem with that advice that setup.py always tries to build bsddbmodule.c when it finds the appropriate headers? I think I've got the same problem on my system ATM. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-28 21:43 Message: Logged In: YES user_id=44345 I agree with Guido. HASHINFO is defined in db185.h. You are trying to compile the older bsddb (now named bsddb185) module using a version of Berkeley DB which was not configured for backward compatibility. When you built Berkeley DB itself did you run configure with the --enable-compat185 flag? If not, you won't be able to compile Modules/bsddbmodule.c. In any case, if you have db-4.x installed, don't bother with the old version of the bsddb module. The new one has a backward compatible API. You should only be building the old version if you are forced to use db-1.85 or db-2.x. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:29 Message: Logged In: YES user_id=6380 Seems something that Skip might understand. Looks to me like you've picked up an incompatible version of the db.h or db_185.h header file... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-02-24 12:22 Message: Logged In: YES user_id=412110 Ok, here it is as an attachment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 09:12 Message: Logged In: YES user_id=6380 Please don't include long listings in the bug report. Attach then separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 From noreply@sourceforge.net Sat Mar 1 08:07:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 00:07:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 12:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Gustavo Niemeyer (niemeyer) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-01 08:07 Message: Logged In: YES user_id=7887 Here is a proposed solution. It has been tested with the standard regression tests, and in an environment with multiple interpreters. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-12 13:13 Message: Logged In: YES user_id=7887 As discussed in python-dev, I'll work on that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 12:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 10:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 12:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Sat Mar 1 14:41:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 06:41:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 07:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: M.-A. Lemburg (lemburg) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 09:41 Message: Logged In: YES user_id=6380 I can't review this beyond "it doesn't break the tests for me"; I suggest to assign to MAL for review. One note: I got a compiler warning implicit declaration of function `_PyCodecRegistry_Init' to fix, add static int _PyCodecRegistry_Init(void); /* Forward */ somewhere to the top of codecs.c. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-01 03:07 Message: Logged In: YES user_id=7887 Here is a proposed solution. It has been tested with the standard regression tests, and in an environment with multiple interpreters. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-12 08:13 Message: Logged In: YES user_id=7887 As discussed in python-dev, I'll work on that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 07:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 05:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 07:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Sat Mar 1 15:15:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 07:15:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 15:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-01 10:15 Message: Logged In: YES user_id=33168 :-) FYI, I do have Windows ME, but no development env't. The best I could do is cygwin. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:24 Message: Logged In: YES user_id=6380 OK, fixed. Who cares if this works on Windows. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:19 Message: Logged In: YES user_id=6380 I'll just check this in -- I don't see any reason to test it on Windows. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:10 Message: Logged In: YES user_id=6380 Neal, do you have a Windows machine to test this on? (It's for Python 2.2.3) (I'm not sure why this needs to be tested on Windows at all - maybe because of the subtle changes to cmd.py?) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-24 17:30 Message: Logged In: YES user_id=80475 Assigning to Neal because I can't test this on my Windows machine. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-21 12:52 Message: Logged In: YES user_id=670441 I'm attaching backported versions against cmd.py 1.26.16.3 readline.c 2.41.6.4 if you want them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 07:42 Message: Logged In: YES user_id=6380 Good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-21 02:42 Message: Logged In: YES user_id=80475 Backport? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-03 06:11 Message: Logged In: YES user_id=6656 Checked in as Lib/cmd.py revision 1.34 Thanks! You probably didn't need to attach the patch three times, though :-) ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:41 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-01 01:37 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-31 16:25 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 11:59 Message: Logged In: YES user_id=670441 That sounds good to me. Go ahead and check in patchcmd. Thanks for your suggestions, I will follow them in future patches. In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!). Okay that's definitely enough commentary for a few line patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-30 05:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 13:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 10:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 05:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Sat Mar 1 17:18:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 09:18:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-695651 ] complex_new does not always respect subtypes Message-ID: Bugs item #695651, was opened at 2003-03-01 08:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: complex_new does not always respect subtypes Initial Comment: On comp.lang.python, David Mertz pointed out this: >>> class ComplexSub(complex): pass ... >>> c = ComplexSub(1+1j) >>> type(c) In other words, trying to create a ComplexSub returns a complex. The problem appears to be this check in complex_new: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL) { I believe the above should also check to see if the type parameter is exactly complex: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL && PyComplex_CheckExact(type)) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 From noreply@sourceforge.net Sat Mar 1 17:27:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 09:27:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-695651 ] complex_new does not always respect subtypes Message-ID: Bugs item #695651, was opened at 2003-03-01 08:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: complex_new does not always respect subtypes Initial Comment: On comp.lang.python, David Mertz pointed out this: >>> class ComplexSub(complex): pass ... >>> c = ComplexSub(1+1j) >>> type(c) In other words, trying to create a ComplexSub returns a complex. The problem appears to be this check in complex_new: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL) { I believe the above should also check to see if the type parameter is exactly complex: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL && PyComplex_CheckExact(type)) { ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-03-01 08:27 Message: Logged In: YES user_id=86307 Oops, obviously that check should be ; if (PyComplex_CheckExact(r) && i == NULL && type == &PyComplex_Type) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 From noreply@sourceforge.net Sat Mar 1 18:02:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 10:02:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-693121 ] Set == non-Set is a TypeError Message-ID: Bugs item #693121, was opened at 2003-02-25 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Reedy (creedy) >Assigned to: Tim Peters (tim_one) Summary: Set == non-Set is a TypeError Initial Comment: Comparing Sets to non-Sets results in a TypeError. For example: >>> from sets import Set >>> x = Set([1]) >>> x == 2 TypeError: Binary operation only permitted between sets This seems to be inconsistent with other Python behavior. For example: >>> (1,2,3) == 2 0 >>> "abcd" == 2 0 Assuming that the standard behavior is what is desired, the implementation of __eq__ and other comparison operators in sets.py should be changed to return NotImplemented when the other object is not a Set. Note: Looking at the code, I'm not sure whether the implementation of __lt__, __le__, etc. should also be changed to not return a Type Error. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-01 13:02 Message: Logged In: YES user_id=80475 That makes sense. What I don't understand is how to implement it. Any change I make to __eq__ and __ne__ causes test_cmp to fail. The new tests are attached. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:48 Message: Logged In: YES user_id=6380 Yes, that's the right solution. In general, more objects should implement this behavior: __eq__, __ne__ return NotImplemented, the others continue to raise TypeError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-28 21:45 Message: Logged In: YES user_id=31435 Short course: returning NotImplemented (== falling back to address comparison, unless the other comparand wants to handle it) instead for __eq__ and __ne__ would be fine. That would be similar to what was done for datetime objects in 2.3a2. The other 4 relationals shouldn't be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:08 Message: Logged In: YES user_id=80475 The OP added this note at the behest of comp.lang.python. The thread is at: http://tinyurl.com/6n91 and includes some comments by Tim. Assigning to Guido to decide whether he wants to keep that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 From noreply@sourceforge.net Sat Mar 1 18:52:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 10:52:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-695688 ] Problems with non-greedy match groups Message-ID: Bugs item #695688, was opened at 2003-03-01 14:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695688&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Daniel (kamek) Assigned to: Fredrik Lundh (effbot) Summary: Problems with non-greedy match groups Initial Comment: The problem is better explained with this code: import re regexp = re.compile(r'^begin ((.*?)X)?(.+) end$') print regexp.search('begin oneXtwo end').groups() # The above one will correctly print: # ('oneX', 'one', 'two') print regexp.search('begin two end').groups() # ...but the above one will print: # (None, 'two end', 'two') # If we change regexp's non-greedy # .*? into .*, it works as it should: # (None, None, 'two') The problem lies in sre; pre correctly matches the non- greedy version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695688&group_id=5470 From noreply@sourceforge.net Sat Mar 1 19:52:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 11:52:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-678519 ] StringIO self-iterator Message-ID: Bugs item #678519, was opened at 2003-02-01 02:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678519&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Raymond Hettinger (rhettinger) Summary: StringIO self-iterator Initial Comment: As requested by Guido at http://mail.python.org/pipermail/python-dev/2003-January/032629.html , this is a feature request to make both cStringIO and StringIO self-iterators (``__iter__()`` returns self and the class defines ``next()``). This is so they can be more like files. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-01 19:52 Message: Logged In: YES user_id=670441 StringIO.StringIO already appears to be a self-iterator. Patch 695710 will make cStringIO.StringIO a self-iterator as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678519&group_id=5470 From noreply@sourceforge.net Sat Mar 1 22:46:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 14:46:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-692416 ] tkinter.createfilehandler dumps core Message-ID: Bugs item #692416, was opened at 2003-02-24 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692416&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mike Romberg (romberg) Assigned to: Martin v. Löwis (loewis) Summary: tkinter.createfilehandler dumps core Initial Comment: This small example probably uses an invalid mask and the filedescriptor for a dummy file. But I'm seeing this core dump even when using a correct mask and sockets. This is with 2.3a2. >>> import Tkinter >>> tk = Tkinter.Tk() >>> fp = open('foo', 'w') >>> def foo(): ... pass ... >>> Tkinter._tkinter.createfilehandler(fp.fileno(), 0, foo) Segmentation fault (core dumped) Here is the traceback: #0 Tkapp_CreateFileHandler (self=0x0, args=0x1) at Modules/_tkinter.c:2205 #1 0x080f279a in PyCFunction_Call (func=0x0, arg=0x40730a68, kw=0x0) at Objects/methodobject.c:108 #2 0x080a73cd in call_function (pp_stack=0xbffff2ec, oparg=1) at Python/ceval.c:3285 #3 0x080a58ed in eval_frame (f=0x815700c) at Python/ceval.c:2041 #4 0x080a630c in PyEval_EvalCodeEx (co=0x40569160, globals=0x0, locals=0x1, args=0x815700c, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2588 #5 0x080a8af7 in PyEval_EvalCode (co=0x1, globals=0x1, locals=0x1) at Python/ceval.c:535 #6 0x080cf25b in run_node (n=0x4015f4e8, filename=0x1
, globals=0x1, locals=0x1, flags=0x1) at Python/pythonrun.c:1105 #7 0x080ce7ae in PyRun_InteractiveOneFlags (fp=0x1, filename=0x80f530a "", flags=0xbffff4d8) at Python/pythonrun.c:609 #8 0x080ce5a3 in PyRun_InteractiveLoopFlags (fp=0x421271c0, filename=0x80f530a "", flags=0x40569160) at Python/pythonrun.c:542 #9 0x080cfae2 in PyRun_AnyFileExFlags (fp=0x421271c0, filename=0x80f530a "", closeit=0, flags=0xbffff4d8) at Python/pythonrun.c:505 #10 0x08054909 in Py_Main (argc=0, argv=0xbffff544) at Modules/main.c:446 #11 0x0805448b in main (argc=1, argv=0x1) at Modules/python.c:23 #12 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-01 17:46 Message: Logged In: YES user_id=33168 The problem is that CHECK_TCL_APPARTMENT is called in Tkapp_CreateFileHandler() and Tkapp_DeleteFileHandler(). The CHECK_TCL_APPARTMENT macro uses self which is NULL when called through the module. Checking if (self == NULL) before calling CHECK_TCL_APPARTMENT would prevent the crash, but I'm not certain this is correct. As a workaround, you should be able to access create/delete filehandler through the instance: w.tk.createfilehandler(...) instead of Tkinter.createfilehandler(...). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 22:10 Message: Logged In: YES user_id=33168 Confirmed the core dump on Linux with Tk 8.3. Hopefully Martin will be back soon. If not I'll try to take a look. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692416&group_id=5470 From noreply@sourceforge.net Sat Mar 1 23:27:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 15:27:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-685773 ] 2 (more) bugs in turtle Message-ID: Bugs item #685773, was opened at 2003-02-13 01:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685773&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Smith (smichr) Assigned to: Nobody/Anonymous (nobody) Summary: 2 (more) bugs in turtle Initial Comment: 1) After initiating filling with the fill(1) command, the next fill command (e.g. fill(0)) does not cause the filling to take place. FIlling does not occur until the next draw statement occurs. SOLUTION: ### At the end of the IF block in fill(), put the following lines as delimited below with the #-- comment: def fill(self, flag): if self._filling: self._items.append(item) #--cps Addition to force filling. Filling doesn't occur until #--a move command is issued, so a "move" to the #--present position is being issued to force the #--filling to occur. x,y=self._position self._goto(x,y) #-- self._path = [] ### 2) The last line of the goto() (not the _goto()) function incorrectly computes the x coordinate as x-x0. You can verify this by issuing a goto(0,0) command as the first turtle command: the turtle wanders off of the origin. SOLUTION The coordinate should be computed as x0+x as shown below (again, this is the last line of the goto() function): self._goto(x0+x, y0-y) /c ---------------------------------------------------------------------- >Comment By: Christopher Smith (smichr) Date: 2003-03-01 17:27 Message: Logged In: YES user_id=514525 Regarding #2, I don't know what I was looking at! :-( I am looking again at the code and it is x0+x, y0-y as it should be. Disregard #2. /c ---------------------------------------------------------------------- Comment By: Christopher Smith (smichr) Date: 2003-02-26 02:21 Message: Logged In: YES user_id=514525 Regarding #1, a better patch has been to name the fill() function as _fill() and create a new fill() function as follows: def fill(self,n): self._fill(n) self.forward(0) #a null move The previous patch from #1 (as I learned) did not fill circles properly. /c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685773&group_id=5470 From noreply@sourceforge.net Sun Mar 2 00:32:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 16:32:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-693121 ] Set == non-Set is a TypeError Message-ID: Bugs item #693121, was opened at 2003-02-25 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Reedy (creedy) Assigned to: Tim Peters (tim_one) Summary: Set == non-Set is a TypeError Initial Comment: Comparing Sets to non-Sets results in a TypeError. For example: >>> from sets import Set >>> x = Set([1]) >>> x == 2 TypeError: Binary operation only permitted between sets This seems to be inconsistent with other Python behavior. For example: >>> (1,2,3) == 2 0 >>> "abcd" == 2 0 Assuming that the standard behavior is what is desired, the implementation of __eq__ and other comparison operators in sets.py should be changed to return NotImplemented when the other object is not a Set. Note: Looking at the code, I'm not sure whether the implementation of __lt__, __le__, etc. should also be changed to not return a Type Error. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-01 19:32 Message: Logged In: YES user_id=31435 This turned out to be messier than I hoped, because Set also implements __cmp__, so returning NotImplented didn't do a lick of good. See the checkin msg and new code comments for discussions of subtleties. Lib/sets.py; new revision: 1.43 Checking in Lib/test/test_sets.py; new revision: 1.21 Misc/NEWS; new revision: 1.685 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-01 13:02 Message: Logged In: YES user_id=80475 That makes sense. What I don't understand is how to implement it. Any change I make to __eq__ and __ne__ causes test_cmp to fail. The new tests are attached. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:48 Message: Logged In: YES user_id=6380 Yes, that's the right solution. In general, more objects should implement this behavior: __eq__, __ne__ return NotImplemented, the others continue to raise TypeError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-28 21:45 Message: Logged In: YES user_id=31435 Short course: returning NotImplemented (== falling back to address comparison, unless the other comparand wants to handle it) instead for __eq__ and __ne__ would be fine. That would be similar to what was done for datetime objects in 2.3a2. The other 4 relationals shouldn't be changed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 21:08 Message: Logged In: YES user_id=80475 The OP added this note at the behest of comp.lang.python. The thread is at: http://tinyurl.com/6n91 and includes some comments by Tim. Assigning to Guido to decide whether he wants to keep that behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693121&group_id=5470 From noreply@sourceforge.net Sun Mar 2 05:06:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 21:06:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-695651 ] complex_new does not always respect subtypes Message-ID: Bugs item #695651, was opened at 2003-03-01 12:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Greg Chapman (glchapman) >Assigned to: Guido van Rossum (gvanrossum) Summary: complex_new does not always respect subtypes Initial Comment: On comp.lang.python, David Mertz pointed out this: >>> class ComplexSub(complex): pass ... >>> c = ComplexSub(1+1j) >>> type(c) In other words, trying to create a ComplexSub returns a complex. The problem appears to be this check in complex_new: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL) { I believe the above should also check to see if the type parameter is exactly complex: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL && PyComplex_CheckExact(type)) { ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-02 00:06 Message: Logged In: YES user_id=31435 Bumped priority & assigned to Guido. Guido, might this be related to that your MyComplex class in pickletester.py isn't used (you left an XXX comment there just noting that it "doesn't work")? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-03-01 12:27 Message: Logged In: YES user_id=86307 Oops, obviously that check should be ; if (PyComplex_CheckExact(r) && i == NULL && type == &PyComplex_Type) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 From noreply@sourceforge.net Sun Mar 2 11:04:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 03:04:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Martin v. Löwis (loewis) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 15:15 Message: Logged In: YES user_id=6656 Hmm, Martin's away and this should probably go in 2.3a2. Anthony, can you give it a once-over? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 19:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 17:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 16:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 15:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 12:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 14:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 12:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 12:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 11:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-16 00:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 19:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 18:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 17:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 16:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 14:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 14:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 12:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Sun Mar 2 11:36:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 03:36:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-221327 ] threads within an embedded python interpreter Message-ID: Bugs item #221327, was opened at 2000-11-03 21:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Martin v. Löwis (loewis) Summary: threads within an embedded python interpreter Initial Comment: I have an application which I am required to embedd a python interpreter inside of a C++ application. The python script creates a separate thread of control to handle a TCP/IP socket connection. The thread can send data just find but hangs on the socket 'recv' fnction. After a dya of debugging my code I went into the python socketmodule.c and at line 1082 I commented out the thread protection code: /*Py_BEGIN_ALLOW_THREADS*/ n = recv(s->sock_fd, PyString_AsString(buf), len, flags); /*Py_END_ALLOW_THREADS*/ I then recompiled the python library and then recompiled my C++ app and everything worked just fine. The problem does not exist when I run the script alone using the python interpreter. Only when I embedd the interpreter, so this is some sort of configuration issue. David Schere Email: david_schere@yahoo.com ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-05 21:21 Message: Logged In: YES user_id=11375 Typo in init.diff: "interpeter" -> "interpReter" in first line. Any reason not to check in the example and close the bug? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 11:47 Message: Logged In: YES user_id=21627 Doc/api/init.tex already has a paragraph about calling Python from a C thread; this patch adds a cookbook example. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 23:58 Message: Logged In: YES user_id=6380 but is it a doco bug or not? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 23:34 Message: Logged In: YES user_id=31392 Probably ought to fix this for 2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-31 21:57 Message: Logged In: NO Now u pay,. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-03 21:44 Message: Most likely, the problem is not the socket module but how you call Python code from a thread that was started from C/C++. Look at t_bootstrap() in threadmodule.c for an example on what to do. (And yes, it's tricky.) There should also be something in the Python/C API documentation about this. I'm not closing the bug report since this is really a documentation issue; it needs to be documented better. I'll assign it to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470 From noreply@sourceforge.net Sun Mar 2 11:45:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 03:45:57 -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: 2003-03-02 12:45 Message: Logged In: YES user_id=21627 Python 2.1.3, in itself, cannot be changed anymore - it has already been released, and for some reason, the time machine won't allow to modify a release... Python 2.1 is essentially not maintained anymore. Anything that is fixed in CVS is marked as fixed in the tracker; if there is interest, backports to 2.2 are still accepted. Either upgrade to 2.2, or accept the bug, or backport the necessary changes. ---------------------------------------------------------------------- Comment By: Florian Konnertz (groovehunter) Date: 2003-02-19 11:49 Message: Logged In: YES user_id=548376 I'm newbie to the Python bug tracker so maybe i missed something, but... ...isn't this issue still open for 2.1.3. See http://openspirit.homelinux.net/noowiki/python/Locale for my error report. ---------------------------------------------------------------------- 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 Mar 2 13:27:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 05:27:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-221327 ] threads within an embedded python interpreter Message-ID: Bugs item #221327, was opened at 2000-11-03 15:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Martin v. Löwis (loewis) Summary: threads within an embedded python interpreter Initial Comment: I have an application which I am required to embedd a python interpreter inside of a C++ application. The python script creates a separate thread of control to handle a TCP/IP socket connection. The thread can send data just find but hangs on the socket 'recv' fnction. After a dya of debugging my code I went into the python socketmodule.c and at line 1082 I commented out the thread protection code: /*Py_BEGIN_ALLOW_THREADS*/ n = recv(s->sock_fd, PyString_AsString(buf), len, flags); /*Py_END_ALLOW_THREADS*/ I then recompiled the python library and then recompiled my C++ app and everything worked just fine. The problem does not exist when I run the script alone using the python interpreter. Only when I embedd the interpreter, so this is some sort of configuration issue. David Schere Email: david_schere@yahoo.com ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 08:27 Message: Logged In: YES user_id=6380 Checked in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-05 15:21 Message: Logged In: YES user_id=11375 Typo in init.diff: "interpeter" -> "interpReter" in first line. Any reason not to check in the example and close the bug? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 05:47 Message: Logged In: YES user_id=21627 Doc/api/init.tex already has a paragraph about calling Python from a C thread; this patch adds a cookbook example. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 17:58 Message: Logged In: YES user_id=6380 but is it a doco bug or not? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 17:34 Message: Logged In: YES user_id=31392 Probably ought to fix this for 2.3 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-31 15:57 Message: Logged In: NO Now u pay,. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-03 15:44 Message: Most likely, the problem is not the socket module but how you call Python code from a thread that was started from C/C++. Look at t_bootstrap() in threadmodule.c for an example on what to do. (And yes, it's tricky.) There should also be something in the Python/C API documentation about this. I'm not closing the bug report since this is really a documentation issue; it needs to be documented better. I'll assign it to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470 From noreply@sourceforge.net Sun Mar 2 14:03:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 06:03:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-695651 ] complex_new does not always respect subtypes Message-ID: Bugs item #695651, was opened at 2003-03-01 12:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Greg Chapman (glchapman) Assigned to: Guido van Rossum (gvanrossum) Summary: complex_new does not always respect subtypes Initial Comment: On comp.lang.python, David Mertz pointed out this: >>> class ComplexSub(complex): pass ... >>> c = ComplexSub(1+1j) >>> type(c) In other words, trying to create a ComplexSub returns a complex. The problem appears to be this check in complex_new: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL) { I believe the above should also check to see if the type parameter is exactly complex: /* Special-case for single argumet that is already complex */ if (PyComplex_CheckExact(r) && i == NULL && PyComplex_CheckExact(type)) { ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 09:03 Message: Logged In: YES user_id=6380 Bingo! Fixed, and checked in. There was another bug waiting to happen once I enabled the pickletester.py change; complex_newargs() contained a segfaulting bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-02 00:06 Message: Logged In: YES user_id=31435 Bumped priority & assigned to Guido. Guido, might this be related to that your MyComplex class in pickletester.py isn't used (you left an XXX comment there just noting that it "doesn't work")? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-03-01 12:27 Message: Logged In: YES user_id=86307 Oops, obviously that check should be ; if (PyComplex_CheckExact(r) && i == NULL && type == &PyComplex_Type) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695651&group_id=5470 From noreply@sourceforge.net Sun Mar 2 20:43:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 12:43:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-16 22:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- >Comment By: Matthew Cowles (mdcowles) Date: 2003-03-02 14:43 Message: Logged In: YES user_id=198518 A week after posting ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 07:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply@sourceforge.net Sun Mar 2 20:56:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 12:56:23 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-696184 ] Enable __slots__ for meta-types Message-ID: Feature Requests item #696184, was opened at 2003-03-02 21:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=696184&group_id=5470 >Category: None >Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Christian Tismer (tismer) Assigned to: Nobody/Anonymous (nobody) Summary: Enable __slots__ for meta-types Initial Comment: The new type system allows non-empty __slots__ only for fixed-size objects. Meta-types are types which instances are also types. types are variable-sized, because they take the slot definitions for their instances, so the cannot have extra members from their meta-type. The proposed solution allows for two things: a) meta-types can have slots b) extensions get access to the whole type object and can create extended types with private fields. The changes providing this are quite simple: - replace the internal hidden "etype" and turn it into an explicit PyHeapTypeObject in object.h - instead of a fixed offset into the former etype, the slots calculation is based upon tp_basicsize. To keep things easy, I added a macro which does this calculation, and member access read now like so: before: type->tp_members = et->members; after: type->tp_members = PyHeapType_GET_MEMBERS(et); This patch has been tested thoroughly in my own code since Python 2.2, and I think it is ripe to get into the distribution. It has almost no impact on speed or complexity. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=696184&group_id=5470 From noreply@sourceforge.net Sun Mar 2 21:26:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 13:26:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-696206 ] Move modules out of Carbon Message-ID: Bugs item #696206, was opened at 2003-03-02 22:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 From noreply@sourceforge.net Sun Mar 2 23:17:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 15:17:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-696253 ] PyMac_GetFSRef should accept unicode Message-ID: Bugs item #696253, was opened at 2003-03-03 00:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696253&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetFSRef should accept unicode Initial Comment: PyMac_GetFSRef() should accept a unicode filename argument, especially since calls like os.dir() can return unicode strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696253&group_id=5470 From noreply@sourceforge.net Sun Mar 2 23:26:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 15:26:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-696261 ] os.path.walk and non-ascii dirnames on MacOSX Message-ID: Bugs item #696261, was opened at 2003-03-03 00:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696261&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: os.path.walk and non-ascii dirnames on MacOSX Initial Comment: os.path.walk will fail if it encounters a non-ascii directory name. The listdir() in the previous iteration will return the directory as a unicode string, but the next iteration will fail on that same unicode string. There is probably something wrong with the file system encoding used on Mac OS X. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696261&group_id=5470 From noreply@sourceforge.net Mon Mar 3 01:19:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 17:19:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-16 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 20:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-02 15:43 Message: Logged In: YES user_id=198518 A week after posting ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 08:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply@sourceforge.net Mon Mar 3 09:14:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 01:14:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i Message-ID: Bugs item #694431, was opened at 2003-02-27 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.3a2 Build fails on HP-UX11i Initial Comment: While building Python 2.3a2 on HP-UX11i I got the following error: ld -b build/temp.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.o -L/opt/python/lib - L/usr/local/lib -o build/lib.hp-ux-B.11.11- 9000/785-2.3/_iconv_codec.sl /usr/lib/dld.sl: Unresolved symbol: libiconv_open (code) from build/lib.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.sl sh[3]: 25624 Abort(coredump) *** Error exit code 134 ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2003-03-03 09:14 Message: Logged In: YES user_id=200117 Sorry for the delay but I had to download from CVS at home yesterday (Sunday 2nd) and build on HP-UX at work today. Unfortunately I'm still getting the same linker error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 17:37 Message: Logged In: YES user_id=33168 This iconv_codec problem may be fixed. Please test with current CVS to verify. See SF bug #690012. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 03:45 Message: Logged In: YES user_id=33168 Richard, can you try the latest version from CVS. I don't have this problem on hp-ux-B.11.00-9000/829 I do have a problem with readline, but I think that's specific to the machine I'm building on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 From noreply@sourceforge.net Mon Mar 3 10:40:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 02:40:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails Message-ID: Bugs item #678217, was opened at 2003-01-31 17:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging fails Initial Comment: When I run the test suite, test_logging sometimes fails. It misses the following output and gets a bunch of exceptions llike the one I included at the end. I haven't counted, but I'd guess that there's one traceback for each missing line of output. test test_logging produced unexpected output: ********************************************************************** *** lines 489-514 of expected output missing: - ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR) - ERR -> ERROR: Message 1 (via logrecv.tcp.ERR) - INF -> CRITICAL: Message 2 (via logrecv.tcp.INF) - INF -> ERROR: Message 3 (via logrecv.tcp.INF) - INF -> WARN: Message 4 (via logrecv.tcp.INF) - INF -> INFO: Message 5 (via logrecv.tcp.INF) - INF.UNDEF -> CRITICAL: Message 6 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF) - INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR) - INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR) - INF.ERR.UNDEF -> CRITICAL: Message 12 (via logrecv.tcp.INF.ERR.UNDEF) - INF.ERR.UNDEF -> ERROR: Message 13 (via logrecv.tcp.INF.ERR.UNDEF) - DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB) - DEB -> ERROR: Message 15 (via logrecv.tcp.DEB) - DEB -> WARN: Message 16 (via logrecv.tcp.DEB) - DEB -> INFO: Message 17 (via logrecv.tcp.DEB) - DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB) - UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF) - UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF) - UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF) - UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF) - INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via logrecv.tcp.INF.BADPARENT.UNDEF) - INF.BADPARENT -> CRITICAL: Message 24 (via logrecv.tcp.INF.BADPARENT) - INF -> INFO: Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ********************************************************************** Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 11:40 Message: Logged In: YES user_id=45365 I see this problem on MacPython-OS9 too, occasionally. So if it is closed I would like to hear the resolution, please... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-01 03:02 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 From noreply@sourceforge.net Mon Mar 3 10:54:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 02:54:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-692416 ] tkinter.createfilehandler dumps core Message-ID: Bugs item #692416, was opened at 2003-02-24 19:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692416&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Mike Romberg (romberg) Assigned to: Martin v. Löwis (loewis) Summary: tkinter.createfilehandler dumps core Initial Comment: This small example probably uses an invalid mask and the filedescriptor for a dummy file. But I'm seeing this core dump even when using a correct mask and sockets. This is with 2.3a2. >>> import Tkinter >>> tk = Tkinter.Tk() >>> fp = open('foo', 'w') >>> def foo(): ... pass ... >>> Tkinter._tkinter.createfilehandler(fp.fileno(), 0, foo) Segmentation fault (core dumped) Here is the traceback: #0 Tkapp_CreateFileHandler (self=0x0, args=0x1) at Modules/_tkinter.c:2205 #1 0x080f279a in PyCFunction_Call (func=0x0, arg=0x40730a68, kw=0x0) at Objects/methodobject.c:108 #2 0x080a73cd in call_function (pp_stack=0xbffff2ec, oparg=1) at Python/ceval.c:3285 #3 0x080a58ed in eval_frame (f=0x815700c) at Python/ceval.c:2041 #4 0x080a630c in PyEval_EvalCodeEx (co=0x40569160, globals=0x0, locals=0x1, args=0x815700c, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2588 #5 0x080a8af7 in PyEval_EvalCode (co=0x1, globals=0x1, locals=0x1) at Python/ceval.c:535 #6 0x080cf25b in run_node (n=0x4015f4e8, filename=0x1
, globals=0x1, locals=0x1, flags=0x1) at Python/pythonrun.c:1105 #7 0x080ce7ae in PyRun_InteractiveOneFlags (fp=0x1, filename=0x80f530a "", flags=0xbffff4d8) at Python/pythonrun.c:609 #8 0x080ce5a3 in PyRun_InteractiveLoopFlags (fp=0x421271c0, filename=0x80f530a "", flags=0x40569160) at Python/pythonrun.c:542 #9 0x080cfae2 in PyRun_AnyFileExFlags (fp=0x421271c0, filename=0x80f530a "", closeit=0, flags=0xbffff4d8) at Python/pythonrun.c:505 #10 0x08054909 in Py_Main (argc=0, argv=0xbffff544) at Modules/main.c:446 #11 0x0805448b in main (argc=1, argv=0x1) at Modules/python.c:23 #12 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 11:54 Message: Logged In: YES user_id=21627 This is now fixed in _tkinter.c 1.150 (also for createtimerhandler). In threaded Tcl, createfilehandler can't really work if invoked from a different thread, so you will have to use a non-threaded Tcl to continue to use _tkinter.createfilehandler. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-01 23:46 Message: Logged In: YES user_id=33168 The problem is that CHECK_TCL_APPARTMENT is called in Tkapp_CreateFileHandler() and Tkapp_DeleteFileHandler(). The CHECK_TCL_APPARTMENT macro uses self which is NULL when called through the module. Checking if (self == NULL) before calling CHECK_TCL_APPARTMENT would prevent the crash, but I'm not certain this is correct. As a workaround, you should be able to access create/delete filehandler through the instance: w.tk.createfilehandler(...) instead of Tkinter.createfilehandler(...). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-26 04:10 Message: Logged In: YES user_id=33168 Confirmed the core dump on Linux with Tk 8.3. Hopefully Martin will be back soon. If not I'll try to take a look. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692416&group_id=5470 From noreply@sourceforge.net Mon Mar 3 10:57:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 02:57:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-27 02:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 11:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Mon Mar 3 11:18:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 03:18:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Michael Hudson (mwh) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 12:18 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it (along with a NEWS entry). Also file a bug report indicating that the warning should be added in 2.4, or come up with another place to collect things that need to be changed in a future version (there are quite a number of such transitions going on). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 15:15 Message: Logged In: YES user_id=6656 Hmm, Martin's away and this should probably go in 2.3a2. Anthony, can you give it a once-over? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 19:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 17:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 16:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 15:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 12:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 14:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 12:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 12:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 11:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-16 00:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 19:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 18:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 17:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 16:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 14:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 14:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 12:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Mon Mar 3 11:46:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 03:46:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-690214 ] robotparser only applies first applicable rule Message-ID: Bugs item #690214, was opened at 2003-02-20 19:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690214&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Pilgrim (f8dy) Assigned to: Nobody/Anonymous (nobody) Summary: robotparser only applies first applicable rule Initial Comment: robotparser robotparser.py::RobotFileParser::can_fetch currently returns the result of the first applicable rule. It should loop through all rules looking for anything that disallows access. For example, if your first rule applies to 'wget' and 'python' and disallows access to /dir1/, and your second rule is a 'python' rule that disallows access to /dir2/, robotparser will falsely claim that python is allowed to access /dir2/. Patch against current source attached. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2003-03-03 12:46 Message: Logged In: YES user_id=9205 Mark, if you dive into http://www.robotstxt.org/wc/norobots-rfc.txt you'll note that the first matching user-agent line as well as the first matching allow or disallow line must be obeyed by the robot (see 3.2.1 and 3.2.2). Now, I am not opposed to disobey the above rfc, but there are other arguments against your patch: a) it breaks current implementations of robots.txt (potentially disallowing access to sites) b) your problem is easily solved by moving Disallow and/or User-Agent lines to the top Therefore my count is -1 for this patch. Cheers, Bastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690214&group_id=5470 From noreply@sourceforge.net Mon Mar 3 12:10:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 04:10:59 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-691291 ] codecs.open(filename, 'U', 'UTF-16') corrupts text Message-ID: Feature Requests item #691291, was opened at 2003-02-22 20:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=691291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Jack Jansen (jackjansen) Summary: codecs.open(filename, 'U', 'UTF-16') corrupts text Initial Comment: Tested in Python 2.3a1. If I write u'Hello\r\nworld\r\n' to a file, then read it back in 'U' mode, I should get u'Hello\nworld\n'. However, if I do this using codecs.open() and the UTF-16 encoding, I get u'Hello\n\nworld\n\n'. codecs.open() is not 'U'-mode-aware. The underlying file is opened in universal newline mode, so the byte '\x0d' is erroneously translated to '\x0a' before the UTF-16 codec has a chance to decode it. The attached unit test should show specifically what it is that I wish would work. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 13:10 Message: Logged In: YES user_id=45365 The problem is that codecs.open() forces binary mode on the underlying file object, and this defeats the U mode. My feeling is that it should be okay to open the underlying file in text mode, thereby enabling the U flag to be passed. Opening the file in text mode would break, however, if one of the following conditions is met: - there are encodings where 0x0a or 0x0d are valid characters, not end of line. - there are libc implementations where opening a file in text mode has more implications than converting \r or \r\n to \n, i.e. if they change other bytes as well. Re-assigning to MAL, as he put the binary mode in in the first place. If this was just defensive programming we might try taking it out, if there was a real error case with text mode then codecs.open should probably at least signal an error if universal newline mode is requested. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:44 Message: Logged In: YES user_id=38388 I'm turning this into a feature request. codecs.open() does not support 'U' as file mode. Assigning to Jack since he introduced the 'U' mode option. Jack, what can we do about this ? ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2003-02-22 22:17 Message: Logged In: YES user_id=18139 Tested in Python 2.3a2 as well (the bug is still there). Note that this isn't limited to UTF-16. It will affect any encoding that uses the byte '\x0d' to mean anything other than u'\r'. The most common American/European encodings are safe (ASCII, Latin-1 and friends, and UTF-8). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=691291&group_id=5470 From noreply@sourceforge.net Mon Mar 3 12:12:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 04:12:00 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-691291 ] codecs.open(filename, 'U', 'UTF-16') corrupts text Message-ID: Feature Requests item #691291, was opened at 2003-02-22 20:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=691291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) >Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.open(filename, 'U', 'UTF-16') corrupts text Initial Comment: Tested in Python 2.3a1. If I write u'Hello\r\nworld\r\n' to a file, then read it back in 'U' mode, I should get u'Hello\nworld\n'. However, if I do this using codecs.open() and the UTF-16 encoding, I get u'Hello\n\nworld\n\n'. codecs.open() is not 'U'-mode-aware. The underlying file is opened in universal newline mode, so the byte '\x0d' is erroneously translated to '\x0a' before the UTF-16 codec has a chance to decode it. The attached unit test should show specifically what it is that I wish would work. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 13:10 Message: Logged In: YES user_id=45365 The problem is that codecs.open() forces binary mode on the underlying file object, and this defeats the U mode. My feeling is that it should be okay to open the underlying file in text mode, thereby enabling the U flag to be passed. Opening the file in text mode would break, however, if one of the following conditions is met: - there are encodings where 0x0a or 0x0d are valid characters, not end of line. - there are libc implementations where opening a file in text mode has more implications than converting \r or \r\n to \n, i.e. if they change other bytes as well. Re-assigning to MAL, as he put the binary mode in in the first place. If this was just defensive programming we might try taking it out, if there was a real error case with text mode then codecs.open should probably at least signal an error if universal newline mode is requested. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:44 Message: Logged In: YES user_id=38388 I'm turning this into a feature request. codecs.open() does not support 'U' as file mode. Assigning to Jack since he introduced the 'U' mode option. Jack, what can we do about this ? ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2003-02-22 22:17 Message: Logged In: YES user_id=18139 Tested in Python 2.3a2 as well (the bug is still there). Note that this isn't limited to UTF-16. It will affect any encoding that uses the byte '\x0d' to mean anything other than u'\r'. The most common American/European encodings are safe (ASCII, Latin-1 and friends, and UTF-8). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=691291&group_id=5470 From noreply@sourceforge.net Mon Mar 3 12:15:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 04:15:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-696261 ] os.path.walk and non-ascii dirnames on MacOSX Message-ID: Bugs item #696261, was opened at 2003-03-03 00:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696261&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: os.path.walk and non-ascii dirnames on MacOSX Initial Comment: os.path.walk will fail if it encounters a non-ascii directory name. The listdir() in the previous iteration will return the directory as a unicode string, but the next iteration will fail on that same unicode string. There is probably something wrong with the file system encoding used on Mac OS X. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-03-03 13:15 Message: Logged In: YES user_id=92689 No, the problem is that os.listdir() doesn't do the right thing with Unicode strings. I have a fix here but I need to rebuild and test. I also need to think about MvL's comment on patch #683592. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696261&group_id=5470 From noreply@sourceforge.net Mon Mar 3 12:15:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 04:15:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-696261 ] os.path.walk and non-ascii dirnames on MacOSX Message-ID: Bugs item #696261, was opened at 2003-03-03 00:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696261&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: os.path.walk and non-ascii dirnames on MacOSX Initial Comment: os.path.walk will fail if it encounters a non-ascii directory name. The listdir() in the previous iteration will return the directory as a unicode string, but the next iteration will fail on that same unicode string. There is probably something wrong with the file system encoding used on Mac OS X. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 13:15 Message: Logged In: YES user_id=45365 Closing this, the discussion now takes place in #683592. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-03-03 13:15 Message: Logged In: YES user_id=92689 No, the problem is that os.listdir() doesn't do the right thing with Unicode strings. I have a fix here but I need to rebuild and test. I also need to think about MvL's comment on patch #683592. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696261&group_id=5470 From noreply@sourceforge.net Mon Mar 3 12:38:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 04:38:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-684975 ] IDE asks for attention when quitting Message-ID: Bugs item #684975, was opened at 2003-02-12 00:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=684975&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IDE asks for attention when quitting Initial Comment: When you quit the IDE (in MacPython-OSX) via the popup menu in the dock it somehow asks for attention (the icon jumps up and down enthusiastically). When you the bring it to front it exits normally, without showing any message or anything. I've looked at this a couple of times but never managed to find what is going on. Do you have any idea? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 13:38 Message: Logged In: YES user_id=45365 Fixed in PythonIDEMain.py rev. 1.31. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-28 17:31 Message: Logged In: YES user_id=92689 That sounds entirely reasonable... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-28 17:05 Message: Logged In: YES user_id=45365 Found the problem: the unconditional call to AEInteractWithUser() in the quit appleevent handler. I think this should be done differently. I've noticed that on OSX it's always safe to call AEInteractWithUser, even when not inside an AE handler. So, the simplest solution would be to call it in all the EasyDialogs calls and be done with it. Do you think this is reasonable? If so assign back to me and I'll do it. The alternative is to do this for IDE only. That means that the various classes should call app.interact() before posting a dialog. app.interact() would then call AEInteractWithUser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=684975&group_id=5470 From noreply@sourceforge.net Mon Mar 3 12:42:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 04:42:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Michael Hudson (mwh) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-03 12:42 Message: Logged In: YES user_id=6656 We got there in the end! Checked in as Misc/NEWS revision 1.686 Lib/test/test_ioctl.py revision 1.1 Doc/lib/libfcntl.tex revision 1.31 Modules/fcntlmodule.c revision 2.38 Not closing because of the "change needed in 2.4" bit -- should there be a PEP for this? Or would a bug in the tracker do? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 11:18 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it (along with a NEWS entry). Also file a bug report indicating that the warning should be added in 2.4, or come up with another place to collect things that need to be changed in a future version (there are quite a number of such transitions going on). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 14:15 Message: Logged In: YES user_id=6656 Hmm, Martin's away and this should probably go in 2.3a2. Anthony, can you give it a once-over? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 18:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 16:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 15:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 14:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 11:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 13:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 11:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 11:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 10:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 23:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 18:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 17:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 16:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 15:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 13:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 13:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 11:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Mon Mar 3 13:01:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 05:01:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-696527 ] Carbon.CF module needs new style classes Message-ID: Bugs item #696527, was opened at 2003-03-03 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696527&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.CF module needs new style classes Initial Comment: Carbon.CF is the only Mac toolbox module that hasn't been converted to new-style classes yet, even though it is probably the one that would benefit most. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696527&group_id=5470 From noreply@sourceforge.net Mon Mar 3 13:08:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 05:08:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Michael Hudson (mwh) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 14:08 Message: Logged In: YES user_id=21627 Creating a new bug report and closing this one would be best, IMO, otherwise, everybody has to read through all these messages to find out that it is still open just because of a tiny detail. I'd title it Python 2.4: Warn about omitted mutable_flag. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-03 13:42 Message: Logged In: YES user_id=6656 We got there in the end! Checked in as Misc/NEWS revision 1.686 Lib/test/test_ioctl.py revision 1.1 Doc/lib/libfcntl.tex revision 1.31 Modules/fcntlmodule.c revision 2.38 Not closing because of the "change needed in 2.4" bit -- should there be a PEP for this? Or would a bug in the tracker do? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 12:18 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it (along with a NEWS entry). Also file a bug report indicating that the warning should be added in 2.4, or come up with another place to collect things that need to be changed in a future version (there are quite a number of such transitions going on). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 15:15 Message: Logged In: YES user_id=6656 Hmm, Martin's away and this should probably go in 2.3a2. Anthony, can you give it a once-over? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 19:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 17:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 16:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 15:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 12:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 14:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 12:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 12:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 11:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-16 00:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 19:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 18:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 17:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 16:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 14:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 14:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 12:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Mon Mar 3 13:25:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 05:25:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-696535 ] Python 2.4: Warn about omitted mutable_flag. Message-ID: Bugs item #696535, was opened at 2003-03-03 13:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696535&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: Python 2.4: Warn about omitted mutable_flag. Initial Comment: We need to add a warning to fcntl.ioctl() for 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696535&group_id=5470 From noreply@sourceforge.net Mon Mar 3 13:25:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 05:25:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Michael Hudson (mwh) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-03 13:25 Message: Logged In: YES user_id=6656 OK, done: 696535. I added a Python 2.4 category :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 13:08 Message: Logged In: YES user_id=21627 Creating a new bug report and closing this one would be best, IMO, otherwise, everybody has to read through all these messages to find out that it is still open just because of a tiny detail. I'd title it Python 2.4: Warn about omitted mutable_flag. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-03 12:42 Message: Logged In: YES user_id=6656 We got there in the end! Checked in as Misc/NEWS revision 1.686 Lib/test/test_ioctl.py revision 1.1 Doc/lib/libfcntl.tex revision 1.31 Modules/fcntlmodule.c revision 2.38 Not closing because of the "change needed in 2.4" bit -- should there be a PEP for this? Or would a bug in the tracker do? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 11:18 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it (along with a NEWS entry). Also file a bug report indicating that the warning should be added in 2.4, or come up with another place to collect things that need to be changed in a future version (there are quite a number of such transitions going on). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 14:15 Message: Logged In: YES user_id=6656 Hmm, Martin's away and this should probably go in 2.3a2. Anthony, can you give it a once-over? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 18:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 16:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 15:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 14:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 11:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 13:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 11:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 11:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 10:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 23:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 18:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 17:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 16:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 15:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 13:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 13:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 11:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Mon Mar 3 13:30:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 05:30:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-682215 ] Carbon.CF.CFString should require ASCII Message-ID: Bugs item #682215, was opened at 2003-02-07 10:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682215&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.CF.CFString should require ASCII Initial Comment: If a Python string is passed where a CFString is expected the bytes are used verbatim (using CFStringCreateWithCString()), but this is probably wrong. We should either allow only ASCII or use sys.getdefaultencoding() or something similar. This is a copy of PyObjC bug . ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 14:30 Message: Logged In: YES user_id=45365 Implemented in CVS. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-07 16:14 Message: Logged In: YES user_id=92689 You can strike the "probably". Although the rest of Python uses the default encoding, I think it's actually wise to just use ASCII and nudge them towards unicode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682215&group_id=5470 From noreply@sourceforge.net Mon Mar 3 16:15:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 08:15:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-693996 ] email.Parser trashes header Message-ID: Bugs item #693996, was opened at 2003-02-26 17:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693996&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sam Shah (sshah) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser trashes header Initial Comment: email.Parser trashes a long-lined recipient list if it is parsed more than once. The attached interpreter transcript demonstrates this problem. During the first parsing, it rewrites the header of the message (okay). But during the second parsing, recipient C is missing from the list. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-03 11:15 Message: Logged In: YES user_id=12800 This appears to be fixed in the folding-reimpl-branch which will soon be committed to the email 2.5 / python 2.3 head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693996&group_id=5470 From noreply@sourceforge.net Mon Mar 3 16:41:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 08:41:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-682504 ] email: preamble must be \n terminated Message-ID: Bugs item #682504, was opened at 2003-02-07 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682504&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: preamble must be \n terminated Initial Comment: when setting the preamble attribute, one must ensure that the attribute is terminated by "\n". Otherwise the boundary string of the first attachment is output directly behind the preample and all email programs ignore the first attachment. Solution: add a trailing "\n" to the preample ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-03 11:41 Message: Logged In: YES user_id=12800 Fixed in email 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682504&group_id=5470 From noreply@sourceforge.net Mon Mar 3 18:29:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 10:29:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-693955 ] Can't multiply str and bool Message-ID: Bugs item #693955, was opened at 2003-02-26 17:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693955&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Can't multiply str and bool Initial Comment: Bug in 2.3a2+: 'abc' * True raises a TypeError: unsupported operand type(s) for *: 'str' and 'bool' . site.py does: initial_slashes = path.startswith('/'); path = '/'*initial_slashes + path . This now fails. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-03 13:29 Message: Logged In: YES user_id=11375 I can't replicate it, so presumably my tree got messed up at some point. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-28 21:23 Message: Logged In: YES user_id=11375 Hm... puzzling. I'll try to replicate it tomorrow, and will close the bug if I can't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-02-28 20:36 Message: Logged In: YES user_id=80475 C:\pydev>python I cannot reproduce the bug: Python 2.3a2+ (#39, Feb 28 2003, 02:20:12) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 'abc' * True 'abc' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693955&group_id=5470 From noreply@sourceforge.net Mon Mar 3 19:03:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 11:03:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-696771 ] re-syntax.html probably should not refer to \g<0> Message-ID: Bugs item #696771, was opened at 2003-03-03 10:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696771&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: re-syntax.html probably should not refer to \g<0> Initial Comment: In discussing backreferences (\ number), re-syntax.html includes this parenthetical comment: (There is a group 0, which is the entire matched pattern, but it can't be referenced with \0; instead, use \g<0>.) The \g syntax is not supported in regex patterns (only in replacement text for substitutions). Even if it was supported, I can't imagine patterns could ever really support \0 (you'd have infinite regress, right?). Anyway, I suggest removing the parenthetical comment (\g is documented in node104.html in the discussion of re.sub). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696771&group_id=5470 From noreply@sourceforge.net Mon Mar 3 19:12:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 11:12:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-690389 ] register command not listed in command line help Message-ID: Bugs item #690389, was opened at 2003-02-20 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690389&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Stuart Bishop (zenzen) Assigned to: A.M. Kuchling (akuchling) Summary: register command not listed in command line help Initial Comment: The register command is not listed when you run python setup.py --help-commands ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-03 14:12 Message: Logged In: YES user_id=11375 Fixed in rev. 1.18 of distutils/command/__init__.py; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690389&group_id=5470 From noreply@sourceforge.net Mon Mar 3 19:17:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 11:17:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-696777 ] How to make a class iterable using a member generator. Message-ID: Bugs item #696777, was opened at 2003-03-03 12:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: How to make a class iterable using a member generator. Initial Comment: This should probably go at the end of 2.2.5 (LibRef). [I was trying all possible variations of __iter__ returning self, with next() as a method...] """If you are designing a class that should be iterable, i.e. you want to be able to say "for x in myClass:...", and, you also want the convenience of using a member function that is a generator to provide the items, your class' __iter__() method should return "self.myGenerator (self)". The object returned from this call is an iterator- generator that implements both of the required __iter__() and next() methods. Example: class Range10: def __init__(self): self.scale = 5 def __iter__(self): return Range10.generateItems(self) def generateItems(self): for i in range(10): yield i * self.scale There are a couple of subtleties here. First, only "user- defined functions" are converted to methods when accessed through a class or instance, i.e.myObject.foo () will extract the foo function wrap it up as a method object, insert myObject in the argument list and call it (LibRef: 3.2/Callable types/User-defined methods). [thanks to Alex M. for clarifying this issue for me] This automatic conversion does not happen for any other type of objects defined inside class scope. In our case, generateItems() will be a generator-iterator, i.e. not a "user-defined function". Thus the conversion to an instance method does not happen, and it is left as a static method of the class. [this seems like it might be a bug to me...]. To get around this irregularity, make sure your __iter__() calls generateItems() as a static method, and explictly passes self. """ -- bjorn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470 From noreply@sourceforge.net Mon Mar 3 20:05:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 12:05:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-26 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-03 13:05 Message: Logged In: YES user_id=85984 > Try finding out what stdin/stdout/stderr refer to > (with fstat or something). Can you be more specific here? I've attached the output of `fstat -m -p 15437' below in case that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 03:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Mon Mar 3 20:21:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 12:21:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-654846 ] datetime docs need review, LaTeX Message-ID: Bugs item #654846, was opened at 2002-12-16 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: datetime docs need review, LaTeX Initial Comment: The datetime sandbox contains a plain text file, docs.txt, with about 5,500 words of datetime documentation. This needs review by someone other than me, and LaTeXification too. Kill two birds with one tedious stone . ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-03 15:21 Message: Logged In: YES user_id=11375 The datetime docs now seem to be reasonably complete and correctly marked up, so I'm closing this bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-17 23:18 Message: Logged In: YES user_id=31435 Outstanding -- thanks, Andrew! I burned too many candles at both ends while scrambling to finish the code, and I'm sure parts of the docs make no sense. Feel free to bug me in email about the incomprehensible parts. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-17 13:45 Message: Logged In: YES user_id=11375 I'm volunteering for this -- I need to write a whatsnew section on datetime anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 From noreply@sourceforge.net Mon Mar 3 20:22:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 12:22:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-690214 ] robotparser only applies first applicable rule Message-ID: Bugs item #690214, was opened at 2003-02-20 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690214&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Pilgrim (f8dy) >Assigned to: Skip Montanaro (montanaro) Summary: robotparser only applies first applicable rule Initial Comment: robotparser robotparser.py::RobotFileParser::can_fetch currently returns the result of the first applicable rule. It should loop through all rules looking for anything that disallows access. For example, if your first rule applies to 'wget' and 'python' and disallows access to /dir1/, and your second rule is a 'python' rule that disallows access to /dir2/, robotparser will falsely claim that python is allowed to access /dir2/. Patch against current source attached. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2003-03-03 06:46 Message: Logged In: YES user_id=9205 Mark, if you dive into http://www.robotstxt.org/wc/norobots-rfc.txt you'll note that the first matching user-agent line as well as the first matching allow or disallow line must be obeyed by the robot (see 3.2.1 and 3.2.2). Now, I am not opposed to disobey the above rfc, but there are other arguments against your patch: a) it breaks current implementations of robots.txt (potentially disallowing access to sites) b) your problem is easily solved by moving Disallow and/or User-Agent lines to the top Therefore my count is -1 for this patch. Cheers, Bastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690214&group_id=5470 From noreply@sourceforge.net Mon Mar 3 20:17:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 12:17:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-693470 ] licence allowed, but doesn't work Message-ID: Bugs item #693470, was opened at 2003-02-26 02:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693470&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: A.M. Kuchling (akuchling) Summary: licence allowed, but doesn't work Initial Comment: 'licence' is accepted without warning as a keyword argument to setup(), but it doesn't actually work. Spelling it 'license' works as expected. Looks like an attempt to accept common misspellings failed. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-03 15:17 Message: Logged In: YES user_id=11375 Fixed in rev. 1.63 of distutils/dist.py; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693470&group_id=5470 From noreply@sourceforge.net Mon Mar 3 20:54:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 12:54:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-690419 ] can't build bsddb for 2.3a2 Message-ID: Bugs item #690419, was opened at 2003-02-21 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Paul Jarc (prjsf) Assigned to: Skip Montanaro (montanaro) Summary: can't build bsddb for 2.3a2 Initial Comment: I have db-4.1.25 installed, and I'm trying to install Python 2.3a2 with bsddb. The build fails: gcc -fPIC -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/package/misc/spf/python-2.3a2/spf/db/include -c ./Modules/bsddbmodule.c -o Modules/bsddbmodule.o Modules/bsddbmodule.c: In function `newdbhashobject': Modules/bsddbmodule.c:58: `HASHINFO' undeclared (first use in this function) Modules/bsddbmodule.c:58: (Each undeclared identifier is reported only once Modules/bsddbmodule.c:58: for each function it appears in.) Modules/bsddbmodule.c:58: parse error before "info" Modules/bsddbmodule.c:63: `info' undeclared (first use in this function) Modules/bsddbmodule.c:74: warning: implicit declaration of function `dbopen' Modules/bsddbmodule.c:74: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbbtobject': Modules/bsddbmodule.c:106: `BTREEINFO' undeclared (first use in this function) Modules/bsddbmodule.c:106: parse error before "info" Modules/bsddbmodule.c:111: `info' undeclared (first use in this function) Modules/bsddbmodule.c:124: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbrnobject': Modules/bsddbmodule.c:156: `RECNOINFO' undeclared (first use in this function) Modules/bsddbmodule.c:156: parse error before "info" Modules/bsddbmodule.c:162: `info' undeclared (first use in this function) Modules/bsddbmodule.c:182: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `bsddb_dealloc': Modules/bsddbmodule.c:223: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_length': Modules/bsddbmodule.c:252: structure has no member named `seq' Modules/bsddbmodule.c:253: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:255: structure has no member named `seq' Modules/bsddbmodule.c:256: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_subscript': Modules/bsddbmodule.c:276: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:276: parse error before "recno" Modules/bsddbmodule.c:279: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:299: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:299: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_ass_sub': Modules/bsddbmodule.c:327: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:327: parse error before "recno" Modules/bsddbmodule.c:330: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:351: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:351: too few arguments to function Modules/bsddbmodule.c:363: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:363: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_close': Modules/bsddbmodule.c:388: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_keys': Modules/bsddbmodule.c:415: structure has no member named `seq' Modules/bsddbmodule.c:415: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:441: structure has no member named `seq' Modules/bsddbmodule.c:442: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_has_key': Modules/bsddbmodule.c:470: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:470: parse error before "recno" Modules/bsddbmodule.c:474: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:491: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:491: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_set_location': Modules/bsddbmodule.c:509: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:509: parse error before "recno" Modules/bsddbmodule.c:513: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:530: structure has no member named `seq' Modules/bsddbmodule.c:530: `R_CURSOR' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_seq': Modules/bsddbmodule.c:570: structure has no member named `seq' Modules/bsddbmodule.c: In function `bsddb_next': Modules/bsddbmodule.c:608: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_previous': Modules/bsddbmodule.c:613: `R_PREV' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_first': Modules/bsddbmodule.c:618: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_last': Modules/bsddbmodule.c:623: `R_LAST' undeclared (first use in this function) make: *** [Modules/bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2003-03-03 20:54 Message: Logged In: YES user_id=412110 Ok, I enabled _bsddb instead of bsddb, and now it works. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 03:22 Message: Logged In: YES user_id=6380 (Um, I've got that problem alright, but it's on the Python 2.2.x branch... So ignore that.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 02:45 Message: Logged In: YES user_id=6380 Isn't a problem with that advice that setup.py always tries to build bsddbmodule.c when it finds the appropriate headers? I think I've got the same problem on my system ATM. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-03-01 02:43 Message: Logged In: YES user_id=44345 I agree with Guido. HASHINFO is defined in db185.h. You are trying to compile the older bsddb (now named bsddb185) module using a version of Berkeley DB which was not configured for backward compatibility. When you built Berkeley DB itself did you run configure with the --enable-compat185 flag? If not, you won't be able to compile Modules/bsddbmodule.c. In any case, if you have db-4.x installed, don't bother with the old version of the bsddb module. The new one has a backward compatible API. You should only be building the old version if you are forced to use db-1.85 or db-2.x. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 02:29 Message: Logged In: YES user_id=6380 Seems something that Skip might understand. Looks to me like you've picked up an incompatible version of the db.h or db_185.h header file... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-02-24 17:22 Message: Logged In: YES user_id=412110 Ok, here it is as an attachment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 14:12 Message: Logged In: YES user_id=6380 Please don't include long listings in the bug report. Attach then separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 From noreply@sourceforge.net Mon Mar 3 21:06:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 13:06:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-696846 ] CGIHTTPServer doesn't quote arguments correctly on Windows. Message-ID: Bugs item #696846, was opened at 2003-03-03 13:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696846&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't quote arguments correctly on Windows. Initial Comment: In module CGIHTTPServer.py, in the section containing the following: ----- elif self.have_popen2 or self.have_popen3: # Windows -- use popen2 or popen3 to create a subprocess import shutil if self.have_popen3: popenx = os.popen3 else: popenx = os.popen2 cmdline = scriptfile if self.is_python(scriptfile): interp = sys.executable if interp.lower().endswith("w.exe"): # On Windows, use python.exe, not pythonw.exe interp = interp[:-5] + interp[-4:] cmdline = "%s -u %s" % (interp, cmdline) ----- The final line, number 231 in my copy (version 0.4 in Python 2.2.2), doesn't handle filespecs with embedded spaces correctly. A script named, for example, "Powers of two.py" won't be found. This can be fixed by changing the quoting, namely to: cmdline = '%s -u "%s"' % (interp, cmdline) so that the script name in cmdline is quoted properly. Note that embedded spaces in interp could also cause problems (if Python were installed in C:\Program Files\ for example), but though adding "s around the first %s works for commands executed directly within Windows XP's cmd.exe, I couldn't get os.popen3 to handle them. Thanks for your help. Allan Wilson ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696846&group_id=5470 From noreply@sourceforge.net Mon Mar 3 21:28:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 13:28:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-692416 ] tkinter.createfilehandler dumps core Message-ID: Bugs item #692416, was opened at 2003-02-24 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692416&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Mike Romberg (romberg) Assigned to: Martin v. Löwis (loewis) Summary: tkinter.createfilehandler dumps core Initial Comment: This small example probably uses an invalid mask and the filedescriptor for a dummy file. But I'm seeing this core dump even when using a correct mask and sockets. This is with 2.3a2. >>> import Tkinter >>> tk = Tkinter.Tk() >>> fp = open('foo', 'w') >>> def foo(): ... pass ... >>> Tkinter._tkinter.createfilehandler(fp.fileno(), 0, foo) Segmentation fault (core dumped) Here is the traceback: #0 Tkapp_CreateFileHandler (self=0x0, args=0x1) at Modules/_tkinter.c:2205 #1 0x080f279a in PyCFunction_Call (func=0x0, arg=0x40730a68, kw=0x0) at Objects/methodobject.c:108 #2 0x080a73cd in call_function (pp_stack=0xbffff2ec, oparg=1) at Python/ceval.c:3285 #3 0x080a58ed in eval_frame (f=0x815700c) at Python/ceval.c:2041 #4 0x080a630c in PyEval_EvalCodeEx (co=0x40569160, globals=0x0, locals=0x1, args=0x815700c, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2588 #5 0x080a8af7 in PyEval_EvalCode (co=0x1, globals=0x1, locals=0x1) at Python/ceval.c:535 #6 0x080cf25b in run_node (n=0x4015f4e8, filename=0x1
, globals=0x1, locals=0x1, flags=0x1) at Python/pythonrun.c:1105 #7 0x080ce7ae in PyRun_InteractiveOneFlags (fp=0x1, filename=0x80f530a "", flags=0xbffff4d8) at Python/pythonrun.c:609 #8 0x080ce5a3 in PyRun_InteractiveLoopFlags (fp=0x421271c0, filename=0x80f530a "", flags=0x40569160) at Python/pythonrun.c:542 #9 0x080cfae2 in PyRun_AnyFileExFlags (fp=0x421271c0, filename=0x80f530a "", closeit=0, flags=0xbffff4d8) at Python/pythonrun.c:505 #10 0x08054909 in Py_Main (argc=0, argv=0xbffff544) at Modules/main.c:446 #11 0x0805448b in main (argc=1, argv=0x1) at Modules/python.c:23 #12 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 16:28 Message: Logged In: YES user_id=33168 Also fixed for deletefilehandler. Checked in as: * Modules/_tkinter.c 1.151 * Misc/NEWS 1.688 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-03 05:54 Message: Logged In: YES user_id=21627 This is now fixed in _tkinter.c 1.150 (also for createtimerhandler). In threaded Tcl, createfilehandler can't really work if invoked from a different thread, so you will have to use a non-threaded Tcl to continue to use _tkinter.createfilehandler. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-01 17:46 Message: Logged In: YES user_id=33168 The problem is that CHECK_TCL_APPARTMENT is called in Tkapp_CreateFileHandler() and Tkapp_DeleteFileHandler(). The CHECK_TCL_APPARTMENT macro uses self which is NULL when called through the module. Checking if (self == NULL) before calling CHECK_TCL_APPARTMENT would prevent the crash, but I'm not certain this is correct. As a workaround, you should be able to access create/delete filehandler through the instance: w.tk.createfilehandler(...) instead of Tkinter.createfilehandler(...). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 22:10 Message: Logged In: YES user_id=33168 Confirmed the core dump on Linux with Tk 8.3. Hopefully Martin will be back soon. If not I'll try to take a look. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692416&group_id=5470 From noreply@sourceforge.net Mon Mar 3 22:10:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 14:10:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-690419 ] can't build bsddb for 2.3a2 Message-ID: Bugs item #690419, was opened at 2003-02-20 19:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Paul Jarc (prjsf) Assigned to: Skip Montanaro (montanaro) Summary: can't build bsddb for 2.3a2 Initial Comment: I have db-4.1.25 installed, and I'm trying to install Python 2.3a2 with bsddb. The build fails: gcc -fPIC -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/package/misc/spf/python-2.3a2/spf/db/include -c ./Modules/bsddbmodule.c -o Modules/bsddbmodule.o Modules/bsddbmodule.c: In function `newdbhashobject': Modules/bsddbmodule.c:58: `HASHINFO' undeclared (first use in this function) Modules/bsddbmodule.c:58: (Each undeclared identifier is reported only once Modules/bsddbmodule.c:58: for each function it appears in.) Modules/bsddbmodule.c:58: parse error before "info" Modules/bsddbmodule.c:63: `info' undeclared (first use in this function) Modules/bsddbmodule.c:74: warning: implicit declaration of function `dbopen' Modules/bsddbmodule.c:74: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbbtobject': Modules/bsddbmodule.c:106: `BTREEINFO' undeclared (first use in this function) Modules/bsddbmodule.c:106: parse error before "info" Modules/bsddbmodule.c:111: `info' undeclared (first use in this function) Modules/bsddbmodule.c:124: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `newdbrnobject': Modules/bsddbmodule.c:156: `RECNOINFO' undeclared (first use in this function) Modules/bsddbmodule.c:156: parse error before "info" Modules/bsddbmodule.c:162: `info' undeclared (first use in this function) Modules/bsddbmodule.c:182: warning: assignment makes pointer from integer without a cast Modules/bsddbmodule.c: In function `bsddb_dealloc': Modules/bsddbmodule.c:223: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_length': Modules/bsddbmodule.c:252: structure has no member named `seq' Modules/bsddbmodule.c:253: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:255: structure has no member named `seq' Modules/bsddbmodule.c:256: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_subscript': Modules/bsddbmodule.c:276: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:276: parse error before "recno" Modules/bsddbmodule.c:279: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:299: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:299: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_ass_sub': Modules/bsddbmodule.c:327: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:327: parse error before "recno" Modules/bsddbmodule.c:330: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:351: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:351: too few arguments to function Modules/bsddbmodule.c:363: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:363: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_close': Modules/bsddbmodule.c:388: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_keys': Modules/bsddbmodule.c:415: structure has no member named `seq' Modules/bsddbmodule.c:415: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c:441: structure has no member named `seq' Modules/bsddbmodule.c:442: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_has_key': Modules/bsddbmodule.c:470: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:470: parse error before "recno" Modules/bsddbmodule.c:474: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:491: warning: passing arg 2 of pointer to function from incompatible pointer type Modules/bsddbmodule.c:491: too few arguments to function Modules/bsddbmodule.c: In function `bsddb_set_location': Modules/bsddbmodule.c:509: `recno_t' undeclared (first use in this function) Modules/bsddbmodule.c:509: parse error before "recno" Modules/bsddbmodule.c:513: `recno' undeclared (first use in this function) Modules/bsddbmodule.c:530: structure has no member named `seq' Modules/bsddbmodule.c:530: `R_CURSOR' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_seq': Modules/bsddbmodule.c:570: structure has no member named `seq' Modules/bsddbmodule.c: In function `bsddb_next': Modules/bsddbmodule.c:608: `R_NEXT' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_previous': Modules/bsddbmodule.c:613: `R_PREV' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_first': Modules/bsddbmodule.c:618: `R_FIRST' undeclared (first use in this function) Modules/bsddbmodule.c: In function `bsddb_last': Modules/bsddbmodule.c:623: `R_LAST' undeclared (first use in this function) make: *** [Modules/bsddbmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-03-03 14:54 Message: Logged In: YES user_id=412110 Ok, I enabled _bsddb instead of bsddb, and now it works. Sorry for the noise. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 21:22 Message: Logged In: YES user_id=6380 (Um, I've got that problem alright, but it's on the Python 2.2.x branch... So ignore that.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 20:45 Message: Logged In: YES user_id=6380 Isn't a problem with that advice that setup.py always tries to build bsddbmodule.c when it finds the appropriate headers? I think I've got the same problem on my system ATM. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-28 20:43 Message: Logged In: YES user_id=44345 I agree with Guido. HASHINFO is defined in db185.h. You are trying to compile the older bsddb (now named bsddb185) module using a version of Berkeley DB which was not configured for backward compatibility. When you built Berkeley DB itself did you run configure with the --enable-compat185 flag? If not, you won't be able to compile Modules/bsddbmodule.c. In any case, if you have db-4.x installed, don't bother with the old version of the bsddb module. The new one has a backward compatible API. You should only be building the old version if you are forced to use db-1.85 or db-2.x. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-28 20:29 Message: Logged In: YES user_id=6380 Seems something that Skip might understand. Looks to me like you've picked up an incompatible version of the db.h or db_185.h header file... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-02-24 11:22 Message: Logged In: YES user_id=412110 Ok, here it is as an attachment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 08:12 Message: Logged In: YES user_id=6380 Please don't include long listings in the bug report. Attach then separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690419&group_id=5470 From noreply@sourceforge.net Mon Mar 3 22:15:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 14:15:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i Message-ID: Bugs item #694431, was opened at 2003-02-27 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.3a2 Build fails on HP-UX11i Initial Comment: While building Python 2.3a2 on HP-UX11i I got the following error: ld -b build/temp.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.o -L/opt/python/lib - L/usr/local/lib -o build/lib.hp-ux-B.11.11- 9000/785-2.3/_iconv_codec.sl /usr/lib/dld.sl: Unresolved symbol: libiconv_open (code) from build/lib.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.sl sh[3]: 25624 Abort(coredump) *** Error exit code 134 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:15 Message: Logged In: YES user_id=33168 Richard, can you help diagnose further since I can't reproduce on HP-UX 11.00? My initial guess is that iconv_open is in a different location, therefore the linking is faililng. Does man iconv_open reveal what library iconv_open is in? To add directories, etc. to the build/link of iconv, you will need to edit setup.py (or test on the command line). Check around line 620 in setup.py. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-03 04:14 Message: Logged In: YES user_id=200117 Sorry for the delay but I had to download from CVS at home yesterday (Sunday 2nd) and build on HP-UX at work today. Unfortunately I'm still getting the same linker error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 12:37 Message: Logged In: YES user_id=33168 This iconv_codec problem may be fixed. Please test with current CVS to verify. See SF bug #690012. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-27 22:45 Message: Logged In: YES user_id=33168 Richard, can you try the latest version from CVS. I don't have this problem on hp-ux-B.11.00-9000/829 I do have a problem with readline, but I think that's specific to the machine I'm building on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 From noreply@sourceforge.net Mon Mar 3 22:17:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 14:17:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-678264 ] test_resource fails when file size is limited Message-ID: Bugs item #678264, was opened at 2003-01-31 13:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Martin v. Löwis (loewis) Summary: test_resource fails when file size is limited Initial Comment: test_resource does: print resource.RLIM_INFINITY == max I'm not sure of the benefit of this line. For machines which have limited file sizes, it causes the test to fail. Otherwise the test seems to work properly. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 17:17 Message: Logged In: YES user_id=33168 Martin, welcome back! Now I get to assign some bugs to you to see if you have any input. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470 From noreply@sourceforge.net Mon Mar 3 22:17:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 14:17:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX Message-ID: Bugs item #678259, was opened at 2003-01-31 13:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Martin v. Löwis (loewis) Summary: locale.getpreferredencoding fails on AIX Initial Comment: The problem is setting LC_CTYPE to an empty string: >>> locale.setlocale(locale.LC_CTYPE, '') Traceback (most recent call last): File "", line 1, in ? File "/home/neal/python/dist/aix/Lib/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Putting a try/except around the setlocale call in getpreferredencoding allows the test to pass. I don't know if this is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470 From noreply@sourceforge.net Mon Mar 3 22:17:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 14:17:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX Message-ID: Bugs item #678250, was opened at 2003-01-31 12:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Martin v. Löwis (loewis) Summary: test_mmap failling on AIX Initial Comment: test_mmap is failing on a flush while trying to do: Copy-on-write memory map data not written correctly The problem is that the mmap is opened with ACCESS_COPY. This translates to MAP_PRIVATE. On AIX, the msync man page says: "When the MS_SYNC and MAP_PRIVATE flags both are used, the msync subroutine returns an errno value of EINVAL." I'm not sure what the correct fix should be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 From noreply@sourceforge.net Mon Mar 3 23:11:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 15:11:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX Message-ID: Bugs item #678259, was opened at 2003-01-31 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: locale.getpreferredencoding fails on AIX Initial Comment: The problem is setting LC_CTYPE to an empty string: >>> locale.setlocale(locale.LC_CTYPE, '') Traceback (most recent call last): File "", line 1, in ? File "/home/neal/python/dist/aix/Lib/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Putting a try/except around the setlocale call in getpreferredencoding allows the test to pass. I don't know if this is correct. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 00:11 Message: Logged In: YES user_id=21627 What are the relevant environment settings? According to http://nscp.upenn.edu/aix4.3html/libs/basetrf2/setlocale.htm specifying "" as the second argument of setlocale is supported, and means the same thing as it does on all other systems: take locale settings from the user preferences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470 From noreply@sourceforge.net Mon Mar 3 23:50:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 15:50:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-679827 ] Header loses lines, formats strangely Message-ID: Bugs item #679827, was opened at 2003-02-03 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679827&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Header loses lines, formats strangely Initial Comment: Biggest problem: print email.message_from_string("""header: problems \tthis line is lost \tthis is not""") This was caused by revision 1.11 of Header.py which was in response to bug #601392. The bugs notes show that when this change was checked in, side effects were worried about, and this is it. Besides this problem, Header does strange and inconsistent formatting of header strings when breaking lines. Tabs are not consistently taken to be 8 spaces when splitting lines (sometimes they are, sometimes not), and a different module (quopriMIME) handles UN-breaking lines (in the _max_append routine) causing strange formatting. quopriMIME doesn't deal with the max line length quite correctly and in header_encode ignores leading spaces when calculating line length (maybe this is on purpose?) All of these issues probably relate somewhat to the discussion in bug #594893 about how to deal with header lines. Some of this may be related to bug #675420 as well. I have worked a bit on a patch, and could finish it if someone wants to see it, but I would have to ask some questions about how lines should be broken and unbroken (how to deal with whitespace and such) first. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-03 18:50 Message: Logged In: YES user_id=12800 I think this specific problem (labeled "biggest problem" above) is fixed in the folding-reimpl-branch, which will soon be merged to email 2.5 on the python 2.3 trunk (and likely backported to python 2.2.3). Both bugs 594893 and 675420 are still open so I will respond to those on those bug reports. As for the other problems alluded to in this report, please submit separate bug reports for them, and assign them to me. Be sure to upload (not paste as a comment) sample code that illustrates the bug. If the bugs still exist, I will want to add them to the test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679827&group_id=5470 From noreply@sourceforge.net Tue Mar 4 04:19:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 20:19:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-654846 ] datetime docs need review, LaTeX Message-ID: Bugs item #654846, was opened at 2002-12-16 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: datetime docs need review, LaTeX Initial Comment: The datetime sandbox contains a plain text file, docs.txt, with about 5,500 words of datetime documentation. This needs review by someone other than me, and LaTeXification too. Kill two birds with one tedious stone . ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-03 23:19 Message: Logged In: YES user_id=31435 Yup -- thanks, Andrew! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-03 15:21 Message: Logged In: YES user_id=11375 The datetime docs now seem to be reasonably complete and correctly marked up, so I'm closing this bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-17 23:18 Message: Logged In: YES user_id=31435 Outstanding -- thanks, Andrew! I burned too many candles at both ends while scrambling to finish the code, and I'm sure parts of the docs make no sense. Feel free to bug me in email about the incomprehensible parts. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-17 13:45 Message: Logged In: YES user_id=11375 I'm volunteering for this -- I need to write a whatsnew section on datetime anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 From noreply@sourceforge.net Tue Mar 4 04:35:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 20:35: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: Python 2.2.2 >Status: Closed Resolution: Accepted 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: 2003-03-04 04:35 Message: Logged In: YES user_id=7887 Backported as: Objects/fileobject.c: 2.141.6.7 Doc/lib/libstdtypes.tex: 1.80.6.20 Misc/NEWS: 1.337.2.4.2.65 (WTF! :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 12:55 Message: Logged In: YES user_id=6380 Yes, please backport. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-16 18:24 Message: Logged In: YES user_id=7887 Applied as Objects/fileobject.c: 2.172 Doc/lib/libstdtypes.tex: 1.114 Misc/NEWS: 1.563 Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 13:23 Message: Logged In: YES user_id=21627 The patch looks good. Please apply it. If we can both agree that this is a bug fix (as it arranges to return data which were previously silently lost), I suggest to backport the patch also to the 2.2 tree (no further review needed). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 01:55 Message: Logged In: YES user_id=7887 Thanks for noticing that Martin. Here is a new revision, with suggested documentation changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-28 11:00 Message: Logged In: YES user_id=21627 I'm still missing proposed documentation changes. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-27 15:58 Message: Logged In: YES user_id=7887 I'm attaching a new revised patch. I'll also increase the priority, to reflect the serious problems this bug could cause. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 16:18 Message: Logged In: YES user_id=7887 You're right about EAGAIN. The behavior I mentioned seems to be valid only for old Unixes, as presented here: http://www.gnu.org/manual/glibc/html_mono/libc.html So indeed we should check for both. OTOH, the above URL also mentions that EAGAIN can happen in blocking situations as well: "On some systems, reading a large amount of data from a character special file can also fail with EAGAIN if the kernel cannot find enough physical memory to lock down the user's pages." Also, the statement in the documentation you mention isn't true even without my patch. We currently check for "readbytes < requestedbytes" and break the loop if it happens. Indeed, that's one of the reasons that created the second problem I've mentioned. Enforcing this behavior, I could see that mentioned in the URL above: "Any condition that could result in EAGAIN can instead result in a successful read which returns fewer bytes than requested. Calling read again immediately would result in EAGAIN." Thusly, applying this patch we wouldn't be introducing a new behavior, but just enforcing a single behavior in every case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 14:18 Message: Logged In: YES user_id=21627 Depends on what system you have. On Linux-i386, we have #define EWOULDBLOCK EAGAIN so it is necessarily the same thing. Can you report on what system EAGAIN happens even if the file descriptor is non-blocking? As for documentation changes: The documentation currently says Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes) I believe this statement is no longer true: with your changes, it will return less data even without hitting EOF. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 13:50 Message: Logged In: YES user_id=7887 Martin, EAGAIN is not the same as EWOULDBLOCK. While EWOULDBLOCK will only be issued in a situation where the filedescriptor is marked as non-blocking, EAGAIN can happen at any time, including when requestsize == -1 (read everything from the fd). If we're going to handle EAGAIN, we must ensure that the loop is not broken when it happens, instead of using the same solution proposed for EWOULDBLOCK. Do you think we should do that as well? You're right about EWOULDBLOCK not being available. I'll include the required #ifdef, and also the suggested comment. Could you please clarify what you mean in this sentence: "In any case, please update the documentation to describe the special cases that you add.". IMO, the proposed patch is not adding special cases. It's just fixing the algorithm to behave the same way in all situations. In that case, what doucmentation should be updated, in your opinion? Or perhaps you're talking about the proposed e.data solution, which would be used in other cases like EINTR similars? Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 08: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 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 Mar 4 07:00:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 23:00:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX Message-ID: Bugs item #678250, was opened at 2003-01-31 18:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Tim Peters (tim_one) Summary: test_mmap failling on AIX Initial Comment: test_mmap is failing on a flush while trying to do: Copy-on-write memory map data not written correctly The problem is that the mmap is opened with ACCESS_COPY. This translates to MAP_PRIVATE. On AIX, the msync man page says: "When the MS_SYNC and MAP_PRIVATE flags both are used, the msync subroutine returns an errno value of EINVAL." I'm not sure what the correct fix should be. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-04 08:00 Message: Logged In: YES user_id=21627 I think the test is somewhat bogus: It tries to check that modification to an ACCESS_COPY doesn't modify the underlying file, but assumes that .flush becomes a no-op, even though an exception is more reasonable (IMO; errors should never pass silently). So I see two options: Declare that .flush() always raises an exception (and modify implementations that don't produce an exception accordingly), or declare that aspect to be system-dependent, and modify the test (and the documentation) to expect and ignore an exception. Assigning to Tim, as he incorporated that feature into mmap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 From noreply@sourceforge.net Tue Mar 4 10:07:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 02:07:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-04 11:07 Message: Logged In: YES user_id=38388 Same comments as Guido, plus: * in the interpreter state struct you should add the new fields to the end, not in the middle * the finalization phase is moved to a later point in the process; this could cause problems when finalizing codecs -- I guess we'll just have to see whether we get bug reports related to this; perhaps it's better to ZAP the dicts before ZAPping builtins etc. ?! Great work, Gustavo. Please check the patch in with the above changes. Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 15:41 Message: Logged In: YES user_id=6380 I can't review this beyond "it doesn't break the tests for me"; I suggest to assign to MAL for review. One note: I got a compiler warning implicit declaration of function `_PyCodecRegistry_Init' to fix, add static int _PyCodecRegistry_Init(void); /* Forward */ somewhere to the top of codecs.c. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-01 09:07 Message: Logged In: YES user_id=7887 Here is a proposed solution. It has been tested with the standard regression tests, and in an environment with multiple interpreters. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-12 14:13 Message: Logged In: YES user_id=7887 As discussed in python-dev, I'll work on that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 13:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 11:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Tue Mar 4 10:12:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 02:12:15 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-691291 ] codecs.open(filename, 'U', 'UTF-16') corrupts text Message-ID: Feature Requests item #691291, was opened at 2003-02-22 20:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=691291&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) >Assigned to: Nobody/Anonymous (nobody) Summary: codecs.open(filename, 'U', 'UTF-16') corrupts text Initial Comment: Tested in Python 2.3a1. If I write u'Hello\r\nworld\r\n' to a file, then read it back in 'U' mode, I should get u'Hello\nworld\n'. However, if I do this using codecs.open() and the UTF-16 encoding, I get u'Hello\n\nworld\n\n'. codecs.open() is not 'U'-mode-aware. The underlying file is opened in universal newline mode, so the byte '\x0d' is erroneously translated to '\x0a' before the UTF-16 codec has a chance to decode it. The attached unit test should show specifically what it is that I wish would work. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-04 11:12 Message: Logged In: YES user_id=38388 The proper thing to do would be to read the file content as Unicode and then use the .splitlines() method on the resulting data. The latter knows about the various ways you can do line ending in Unicode, including the Mac, DOS and Unix variations. I don't have time for this, so unassigning it again. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 13:10 Message: Logged In: YES user_id=45365 The problem is that codecs.open() forces binary mode on the underlying file object, and this defeats the U mode. My feeling is that it should be okay to open the underlying file in text mode, thereby enabling the U flag to be passed. Opening the file in text mode would break, however, if one of the following conditions is met: - there are encodings where 0x0a or 0x0d are valid characters, not end of line. - there are libc implementations where opening a file in text mode has more implications than converting \r or \r\n to \n, i.e. if they change other bytes as well. Re-assigning to MAL, as he put the binary mode in in the first place. If this was just defensive programming we might try taking it out, if there was a real error case with text mode then codecs.open should probably at least signal an error if universal newline mode is requested. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-02-26 14:44 Message: Logged In: YES user_id=38388 I'm turning this into a feature request. codecs.open() does not support 'U' as file mode. Assigning to Jack since he introduced the 'U' mode option. Jack, what can we do about this ? ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2003-02-22 22:17 Message: Logged In: YES user_id=18139 Tested in Python 2.3a2 as well (the bug is still there). Note that this isn't limited to UTF-16. It will affect any encoding that uses the byte '\x0d' to mean anything other than u'\r'. The most common American/European encodings are safe (ASCII, Latin-1 and friends, and UTF-8). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=691291&group_id=5470 From noreply@sourceforge.net Tue Mar 4 10:33:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 02:33:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-27 02:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 11:33 Message: Logged In: YES user_id=45365 Something like fstat is indeed what I was suggesting. The fstat output shows your Python script is getting stdin from a file, and stdout/stderr go to a pipe (the same one). You also have another pip open on filedescriptors 3/4. Try the same thing on Linux (or another system where things just work) and see if there's a difference in what files are open. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-03 21:05 Message: Logged In: YES user_id=85984 > Try finding out what stdin/stdout/stderr refer to > (with fstat or something). Can you be more specific here? I've attached the output of `fstat -m -p 15437' below in case that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 11:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Tue Mar 4 10:42:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 02:42:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-697179 ] gensuitemodule overhaul Message-ID: Bugs item #697179, was opened at 2003-03-04 11:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697179&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: gensuitemodule overhaul Initial Comment: Gensuitemodule needs an overhaul, if possible before 2.3. Things that need to be done: - Use more MacOSX-compatible ways to get at the AETE. Donovan Preston posted a note on how to use the ascr/gdte call. There's also some interesting-looking calls in the OpenScripting framework. - Distinguish between running while building a distribution (things go into Lib/plat-mac/lib-scriptpackages) and running as a user (things should go into site-packages). - Allow for non-interactive use. Main problem is that some suites need a name-mapping, and there's undefined enums to be catered for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697179&group_id=5470 From noreply@sourceforge.net Tue Mar 4 12:48:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 04:48:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch Message-ID: Bugs item #697220, was opened at 2003-03-04 13:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: string.strip implementation/doc mismatch Initial Comment: #v+ >>> "test".strip("t") 'es' >>> import string >>> print string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> #v- *But* the Python documentation says that not only the string *method* strip() will allow a second optional argument, but also the strip function in the string module. (http://www.python.org/doc/current/lib/module-string.html) string.strip should be changed to accept the additional parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 From noreply@sourceforge.net Tue Mar 4 13:58:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 05:58:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-697256 ] PyMarshal_WriteShortToFile() documented, but not implemented Message-ID: Bugs item #697256, was opened at 2003-03-04 14:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: PyMarshal_WriteShortToFile() documented, but not implemented Initial Comment: $ grep -r PyMarshal_WriteShortToFile * Doc/api/utilities.tex:\begin{cfuncdesc}{void}{PyMarshal_WriteShortToFile}{short value, FILE *file} Include/marshal.h:PyAPI_FUNC(void) PyMarshal_WriteShortToFile(int, FILE *); I guess it is a historic function that was removed at some point? Appears in both Python 2.2.2 and 2.3a2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 From noreply@sourceforge.net Tue Mar 4 14:18:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 06:18:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-696771 ] re-syntax.html probably should not refer to \g<0> Message-ID: Bugs item #696771, was opened at 2003-03-03 14:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696771&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: A.M. Kuchling (akuchling) Summary: re-syntax.html probably should not refer to \g<0> Initial Comment: In discussing backreferences (\ number), re-syntax.html includes this parenthetical comment: (There is a group 0, which is the entire matched pattern, but it can't be referenced with \0; instead, use \g<0>.) The \g syntax is not supported in regex patterns (only in replacement text for substitutions). Even if it was supported, I can't imagine patterns could ever really support \0 (you'd have infinite regress, right?). Anyway, I suggest removing the parenthetical comment (\g is documented in node104.html in the discussion of re.sub). ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-04 09:18 Message: Logged In: YES user_id=11375 Done; I've removed the aside in rev. 1.94 of libre.tex. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696771&group_id=5470 From noreply@sourceforge.net Tue Mar 4 14:23:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 06:23:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-692016 ] LibRef 4.2.1: {m,n} description update Message-ID: Bugs item #692016, was opened at 2003-02-23 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692016&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) >Assigned to: A.M. Kuchling (akuchling) Summary: LibRef 4.2.1: {m,n} description update Initial Comment: LibRef 4.2.1 Regular Expression Syntax {m,n} "...you can't omit m...." Actually, you can: for sre, it defaults to 0 >>> a4=re.compile('a{,4}') >>> a4.match('').group(0) '' >>> a4.match('aaaaa').group(0) 'aaaa' This is predictable from sre_parse.py code elif this == "{": min, max = 0, MAXREPEAT /* lo set to digits between { and ,.*/ if lo: min = atoi(lo) Result for pre seems buggy: compiles but does not match. (so 'can't' is sort of correct, but not in way expected -- by raising exception): >>> import pre >>> pa4=pre.compile('a{,4}') >>> pa4.match('') # None response >>> pa4.match('aaaaa').group(0) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'NoneType' object has no attribute 'group' So, suggested replacement: "For sre, m defaults to 0; for older pre, missing m compiles but does not match." ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-04 09:23 Message: Logged In: YES user_id=11375 Fixed in rev. 1.95 of libre.tex; thanks! I haven't mentioned sre vs. pre, because that's an implementation detail and 'pre' is likely to go away one of these versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692016&group_id=5470 From noreply@sourceforge.net Tue Mar 4 16:17:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 08:17:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-692016 ] LibRef 4.2.1: {m,n} description update Message-ID: Bugs item #692016, was opened at 2003-02-23 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692016&group_id=5470 Category: Documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: A.M. Kuchling (akuchling) Summary: LibRef 4.2.1: {m,n} description update Initial Comment: LibRef 4.2.1 Regular Expression Syntax {m,n} "...you can't omit m...." Actually, you can: for sre, it defaults to 0 >>> a4=re.compile('a{,4}') >>> a4.match('').group(0) '' >>> a4.match('aaaaa').group(0) 'aaaa' This is predictable from sre_parse.py code elif this == "{": min, max = 0, MAXREPEAT /* lo set to digits between { and ,.*/ if lo: min = atoi(lo) Result for pre seems buggy: compiles but does not match. (so 'can't' is sort of correct, but not in way expected -- by raising exception): >>> import pre >>> pa4=pre.compile('a{,4}') >>> pa4.match('') # None response >>> pa4.match('aaaaa').group(0) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'NoneType' object has no attribute 'group' So, suggested replacement: "For sre, m defaults to 0; for older pre, missing m compiles but does not match." ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2003-03-04 11:17 Message: Logged In: YES user_id=593130 Yes: this is consistent with pre's deprecation and removal from re.py (after 2.2.1) and the recent removal (since 2.2.2), from Lib Sect 4.2, of the Implementation Note discussing sre versus pre. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-04 09:23 Message: Logged In: YES user_id=11375 Fixed in rev. 1.95 of libre.tex; thanks! I haven't mentioned sre vs. pre, because that's an implementation detail and 'pre' is likely to go away one of these versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692016&group_id=5470 From noreply@sourceforge.net Tue Mar 4 17:09:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 09:09:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i Message-ID: Bugs item #694431, was opened at 2003-02-27 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.3a2 Build fails on HP-UX11i Initial Comment: While building Python 2.3a2 on HP-UX11i I got the following error: ld -b build/temp.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.o -L/opt/python/lib - L/usr/local/lib -o build/lib.hp-ux-B.11.11- 9000/785-2.3/_iconv_codec.sl /usr/lib/dld.sl: Unresolved symbol: libiconv_open (code) from build/lib.hp-ux-B.11.11-9000/785- 2.3/_iconv_codec.sl sh[3]: 25624 Abort(coredump) *** Error exit code 134 ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2003-03-04 17:09 Message: Logged In: YES user_id=200117 Neal, I will try to help, but internet access is difficult at work so responses may not be prompt. I had a look at the man page but it was not clear to me which library contains iconv_open. I will attach text copy of the man page for you. I also include some nm output from libc.sl which refers to iconv_open, but I'm not sure if it means that it contains the code for the function. Let me know if I can try anything else. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-03 22:15 Message: Logged In: YES user_id=33168 Richard, can you help diagnose further since I can't reproduce on HP-UX 11.00? My initial guess is that iconv_open is in a different location, therefore the linking is faililng. Does man iconv_open reveal what library iconv_open is in? To add directories, etc. to the build/link of iconv, you will need to edit setup.py (or test on the command line). Check around line 620 in setup.py. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-03-03 09:14 Message: Logged In: YES user_id=200117 Sorry for the delay but I had to download from CVS at home yesterday (Sunday 2nd) and build on HP-UX at work today. Unfortunately I'm still getting the same linker error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 17:37 Message: Logged In: YES user_id=33168 This iconv_codec problem may be fixed. Please test with current CVS to verify. See SF bug #690012. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-28 03:45 Message: Logged In: YES user_id=33168 Richard, can you try the latest version from CVS. I don't have this problem on hp-ux-B.11.00-9000/829 I do have a problem with readline, but I think that's specific to the machine I'm building on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470 From noreply@sourceforge.net Tue Mar 4 17:55:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 09:55:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch Message-ID: Bugs item #697220, was opened at 2003-03-04 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 >Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Neal Norwitz (nnorwitz) Summary: string.strip implementation/doc mismatch Initial Comment: #v+ >>> "test".strip("t") 'es' >>> import string >>> print string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> #v- *But* the Python documentation says that not only the string *method* strip() will allow a second optional argument, but also the strip function in the string module. (http://www.python.org/doc/current/lib/module-string.html) string.strip should be changed to accept the additional parameter. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-04 12:55 Message: Logged In: YES user_id=33168 Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before do not. We should really update the doc. I thought this was done, but apparently not. Checked in as: libstring.tex 1.45.8.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 From noreply@sourceforge.net Tue Mar 4 18:10:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 10:10:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch Message-ID: Bugs item #697220, was opened at 2003-03-04 13:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Neal Norwitz (nnorwitz) Summary: string.strip implementation/doc mismatch Initial Comment: #v+ >>> "test".strip("t") 'es' >>> import string >>> print string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> #v- *But* the Python documentation says that not only the string *method* strip() will allow a second optional argument, but also the strip function in the string module. (http://www.python.org/doc/current/lib/module-string.html) string.strip should be changed to accept the additional parameter. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2003-03-04 19:10 Message: Logged In: YES user_id=163326 Neil, I don't think this was implemented in the 2.2 maintenance branch. That's why I'm reopening this. At least for my 2.2 Pythons string.strip accepts one parameter only: 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 string >>> string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> and Python 2.2.2 (#1, Feb 9 2003, 13:22:07) [GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) Confused. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-04 18:55 Message: Logged In: YES user_id=33168 Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before do not. We should really update the doc. I thought this was done, but apparently not. Checked in as: libstring.tex 1.45.8.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 From noreply@sourceforge.net Tue Mar 4 18:20:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 10:20:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch Message-ID: Bugs item #697220, was opened at 2003-03-04 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Neal Norwitz (nnorwitz) Summary: string.strip implementation/doc mismatch Initial Comment: #v+ >>> "test".strip("t") 'es' >>> import string >>> print string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> #v- *But* the Python documentation says that not only the string *method* strip() will allow a second optional argument, but also the strip function in the string module. (http://www.python.org/doc/current/lib/module-string.html) string.strip should be changed to accept the additional parameter. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-04 13:20 Message: Logged In: YES user_id=33168 Thanks, you are correct. The problem was with the string object, not the string module. :-( I need to look at this more. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2003-03-04 13:10 Message: Logged In: YES user_id=163326 Neil, I don't think this was implemented in the 2.2 maintenance branch. That's why I'm reopening this. At least for my 2.2 Pythons string.strip accepts one parameter only: 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 string >>> string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> and Python 2.2.2 (#1, Feb 9 2003, 13:22:07) [GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) Confused. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-04 12:55 Message: Logged In: YES user_id=33168 Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before do not. We should really update the doc. I thought this was done, but apparently not. Checked in as: libstring.tex 1.45.8.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 From noreply@sourceforge.net Tue Mar 4 18:25:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 10:25:27 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-681533 ] Additional string stuff. Message-ID: Feature Requests item #681533, was opened at 2003-02-06 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Additional string stuff. Initial Comment: In a lot of my programs that mess with strings, I end up somewhere making a variable "ascii" via (string.maketrans('', '')). It's just a 256-character string comprising the ascii character set. I use it, oftentimes, simply to be able to turn the 'translate' method on strings into a 'delete' method -- if I want to, say, remove all the spaces in aString, I'd do (aString.translate(ascii, string.whitespace)). Certainly an ascii variable in the string module couldn't hurt, would fit in with ascii_letters, etc. and would at least standarize the name of the full ascii set sure to be present in many Python programs. A little further out there, but I think just as useful, would be a delete method on strings. So "foo bar baz".delete(string.whitespace) would return "foobarbaz". It would be equivalent to "foo bar baz".translate(ascii, string.whitespace), or the wildly inefficient: def delete(s, deleteChars): l = [] for c in s: if c not in deleteChars: l.append(c) return ''.join(l) Anyway, that's all I can think of. Do with it what you will. Jeremy ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-04 13:25 Message: Logged In: YES user_id=99508 What's the status on this? I checked string.py, and there actually already is a value that's the 256 ASCII characters, but it's called _idmap. Might we consider changing the name of that to "ascii"? I'd be happy to make the patch. Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 01:47 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 00:19 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-06 21:15 Message: Logged In: YES user_id=31435 Just noting that you can pass None for sep if you want to explicitly ask for the default behavior. >>> " a b c".split(None, 1) ['a', 'b c'] >>> ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-06 04:19 Message: Logged In: YES user_id=99508 Let me also make one other suggestion: the split method on a string object has, by default, behavior that can't be replicated by passing an argument as a separator. That is, the default separated acts like re.split(r'\s+'), but it's impossible to pass any value into the method to achieve that same result. The problem arises when a user wants to use the maxsplit() parameter to the method. Because maxsplit is a positional parameter instead of a keyword parameter, the user *must* declare a separate to split on, and thus loses his ability to split on whitespace-in-general. If maxsplit was changed from being a positional parameter to being a keyword parameter, then a programmer wouldn't have to give up the default behavior of the split method in order to pass it a maxsplit. At present, negative maxsplit values don't differ in any way from split's default behavior (with no maxsplit parameter given). Thus, the keyword maxsplit could default to -1 with no breakage of code. I can't see any place where changing maxsplit to a keyword parameter would break any existing code Jeremy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 From noreply@sourceforge.net Tue Mar 4 18:45:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 10:45:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-26 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-04 11:45 Message: Logged In: YES user_id=85984 Attached is lsof output on a Linux box. I had to insert a sleep after the write but before the close in order to capture it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 03:33 Message: Logged In: YES user_id=45365 Something like fstat is indeed what I was suggesting. The fstat output shows your Python script is getting stdin from a file, and stdout/stderr go to a pipe (the same one). You also have another pip open on filedescriptors 3/4. Try the same thing on Linux (or another system where things just work) and see if there's a difference in what files are open. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-03 13:05 Message: Logged In: YES user_id=85984 > Try finding out what stdin/stdout/stderr refer to > (with fstat or something). Can you be more specific here? I've attached the output of `fstat -m -p 15437' below in case that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 03:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Tue Mar 4 20:45:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 12:45:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-27 02:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 21:45 Message: Logged In: YES user_id=45365 That confirms my suspicion that this is a third-party error: filedescriptors 2 and 3 are readwrite on BSD, write-only on Linux. A final test to confirm this: on BSD, add code like this just before calling popen(): os.close(1) os.close(2) os.open("/dev/null", "w") os.open("/dev/null", "w") If this makes the hang go away then the real problem is that whatever program executes your .forward (qmail?) erroneously opens a read-write pipe for your stdout and stderr. You can't do this with pipe() AFAIK, but maybe with socketpair() or something. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-04 19:45 Message: Logged In: YES user_id=85984 Attached is lsof output on a Linux box. I had to insert a sleep after the write but before the close in order to capture it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 11:33 Message: Logged In: YES user_id=45365 Something like fstat is indeed what I was suggesting. The fstat output shows your Python script is getting stdin from a file, and stdout/stderr go to a pipe (the same one). You also have another pip open on filedescriptors 3/4. Try the same thing on Linux (or another system where things just work) and see if there's a difference in what files are open. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-03 21:05 Message: Logged In: YES user_id=85984 > Try finding out what stdin/stdout/stderr refer to > (with fstat or something). Can you be more specific here? I've attached the output of `fstat -m -p 15437' below in case that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 11:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Tue Mar 4 21:51:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 13:51:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-697546 ] Tkinter Help menu error with pythonw Message-ID: Bugs item #697546, was opened at 2003-03-04 21:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lopan (corvus) Assigned to: Jack Jansen (jackjansen) Summary: Tkinter Help menu error with pythonw Initial Comment: Note: Test script attached which demonstrates this problem. If I launch my application using pythonw, then the first item in its 'Help' menu is an extraneous 'x' which I didn't put there, and can't seem to get rid of. Actually, when I first switch to the application, each item in my Help menu is an 'x'. If I switch to another app then back, my menu items have their names back, and there's still the first mysterious 'x'. If I wrap my application up into an applicaiton bundle (foo.app), and run it that way, the menus work as they should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 From noreply@sourceforge.net Tue Mar 4 22:02:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 14:02:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-697556 ] test_posix fails: getlogin Message-ID: Bugs item #697556, was opened at 2003-03-04 22:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: test_posix fails: getlogin Initial Comment: I see bug #690081 made this run only in interactive mode, but it still fails for me when I do a make test. Apparently my utmp is in an unexpected place, /var/run/, which I guess doesn't agree with my libc? I don't know how common this bug will be for other people, but if anyone else experiences it you should probably just get rid of the getlogin test altogether, or at least catch the OSError: (2, 'No such file or directory') and don't have that mean test failure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 From noreply@sourceforge.net Tue Mar 4 22:03:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 14:03:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-697546 ] Tkinter Help menu error with pythonw Message-ID: Bugs item #697546, was opened at 2003-03-04 21:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lopan (corvus) Assigned to: Jack Jansen (jackjansen) Summary: Tkinter Help menu error with pythonw Initial Comment: Note: Test script attached which demonstrates this problem. If I launch my application using pythonw, then the first item in its 'Help' menu is an extraneous 'x' which I didn't put there, and can't seem to get rid of. Actually, when I first switch to the application, each item in my Help menu is an 'x'. If I switch to another app then back, my menu items have their names back, and there's still the first mysterious 'x'. If I wrap my application up into an applicaiton bundle (foo.app), and run it that way, the menus work as they should. ---------------------------------------------------------------------- >Comment By: David Lopan (corvus) Date: 2003-03-04 22:03 Message: Logged In: YES user_id=2138 It doesn't looke like my attachment worked. Here's the script: #!/usr/local/bin/pythonw import Tkinter def hello(): print "hello" root = Tkinter.Tk() root.title('menubar test') menubar = Tkinter.Menu(root) helpmenu = Tkinter.Menu(menubar, name='help', tearoff=0) menubar.add_cascade(label="Help", menu=helpmenu, underline=0) addhelp = helpmenu.add_command addhelp(label='Window Help', underline=0, command=hello, state='normal') addhelp(label='Menu Help', underline=9, command=hello, state='normal') helpmenu.add_separator() addhelp(label='About Assignments', underline=0, command=hello) root.configure(menu=menubar) root.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 From noreply@sourceforge.net Tue Mar 4 22:28:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 14:28:57 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-697575 ] Warn on potentially useless umasks? Message-ID: Feature Requests item #697575, was opened at 2003-03-04 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697575&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: A.M. Kuchling (akuchling) Summary: Warn on potentially useless umasks? Initial Comment: I noticed quite by accident today that distutils seems to take into account the installer's umask setting when spambayes got installed with these notices: changing mode of /usr/local/bin/unheader.py to 711 changing mode of /usr/local/bin/hammie.py to 711 changing mode of /usr/local/bin/hammiecli.py to 711 changing mode of /usr/local/bin/hammiesrv.py to 711 ... The root user's umask was 077. Perhaps distutils should warn the installer when scripts or modules would be installed but not readable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697575&group_id=5470 From noreply@sourceforge.net Tue Mar 4 22:51:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 14:51:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Nobody/Anonymous (nobody) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Tue Mar 4 22:42:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 14:42:41 -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 08: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. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-03-04 22:42 Message: Logged In: YES user_id=60903 Attached is a patch sent to the Debian BTS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 From noreply@sourceforge.net Tue Mar 4 23:26:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 15:26:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-670311 ] sys.exit and PYTHONINSPECT Message-ID: Bugs item #670311, was opened at 2003-01-18 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: sys.exit and PYTHONINSPECT Initial Comment: If you invoke the Python interpreter with -i, then even sys.exit shouldn't kill the interpreter, especially since sys.exit generates a SystemExit exception which can be caught. I can't think of any other case where -i fails to keep the interpreter alive after a script exits, whether because of an syntax or runtime error or normal termination. I started a thread on python-dev about this issue: http://mail.python.org/pipermail/python-dev/2003- January/032217.html ka ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-04 23:26 Message: Logged In: YES user_id=670441 See patch 697613 for a possible fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 From noreply@sourceforge.net Wed Mar 5 01:50:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 17:50:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Nobody/Anonymous (nobody) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 5 02:18:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 04 Mar 2003 18:18:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) >Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:04:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:04:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-697546 ] Tkinter Help menu error with pythonw Message-ID: Bugs item #697546, was opened at 2003-03-04 22:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Jack Jansen (jackjansen) Summary: Tkinter Help menu error with pythonw Initial Comment: Note: Test script attached which demonstrates this problem. If I launch my application using pythonw, then the first item in its 'Help' menu is an extraneous 'x' which I didn't put there, and can't seem to get rid of. Actually, when I first switch to the application, each item in my Help menu is an 'x'. If I switch to another app then back, my menu items have their names back, and there's still the first mysterious 'x'. If I wrap my application up into an applicaiton bundle (foo.app), and run it that way, the menus work as they should. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 14:04 Message: Logged In: YES user_id=45365 I can repeat this, and I think I know where the problem lies. Unfortunately I don't know how to fix it, yet. Apparently something goes wrong because Python.app (which is used by pythonw) has plist file entries CFBundleHelp*, which cause it to get a help menu. This causes a help menu to be created automatically, which seems to interfere with Tk's own manual creation of a help menu. A workaround is easy: remove those entries from the Python.app plist file and everything is fine. The problem is that I need somewhere to put the Python documentation, and it has to be a .app bundle (that's the only thing AHRegisterHelpBook will accept). That is: I may be able to use a .help bundle, I've come across them. I will investigate, and if this works I'll fix Python.app. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 23:03 Message: Logged In: YES user_id=2138 It doesn't looke like my attachment worked. Here's the script: #!/usr/local/bin/pythonw import Tkinter def hello(): print "hello" root = Tkinter.Tk() root.title('menubar test') menubar = Tkinter.Menu(root) helpmenu = Tkinter.Menu(menubar, name='help', tearoff=0) menubar.add_cascade(label="Help", menu=helpmenu, underline=0) addhelp = helpmenu.add_command addhelp(label='Window Help', underline=0, command=hello, state='normal') addhelp(label='Menu Help', underline=9, command=hello, state='normal') helpmenu.add_separator() addhelp(label='About Assignments', underline=0, command=hello) root.configure(menu=menubar) root.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:36:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:36:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-697983 ] Mention gmtime in Chapter 6.9 "Time access and conversions" Message-ID: Bugs item #697983, was opened at 2003-03-05 14:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697983&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Mention gmtime in Chapter 6.9 "Time access and conversions" Initial Comment: The function gmtime is in the calendar module, but is highly related to the functions in the time module. I therefore suggest that chapter 6.9 "Time access and conversions" mention the existance of the gmtime function. Furthermore I would suggest that the gmtime function would suit better in the time module than the calendar module, but I will make this a separate request for enhancement... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697983&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:40:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:40:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-697985 ] Move gmtime function from calendar to time module Message-ID: Bugs item #697985, was opened at 2003-03-05 14:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697985&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:43:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:43:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-697986 ] Clarify timegm documentation Message-ID: Bugs item #697986, was opened at 2003-03-05 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697986&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify timegm documentation Initial Comment: Python Library Reference Chapter 5.13: timegm. I assume that this function, taking a tm tuple as input, ignores the weekday and Julian day values in the tuple, just like mktime does in C. This should be documented. See also bug #697983 and RFE #697985 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697986&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:46:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:46:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-697988 ] Clarify daylight variable meaning Message-ID: Bugs item #697988, was opened at 2003-03-05 14:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697988&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify daylight variable meaning Initial Comment: Python Library Reference: Chapter 6.9 Clarify what the daylight variable means - is it true if daylight savings time is in effect in the local time zone, or is it true if the local time zone has daylight savings time during some part of the year? I think the correct answer is the latter, by comparing with C documentation. This should be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697988&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:46:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:46:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-697989 ] Clarify mktime semantics Message-ID: Bugs item #697989, was opened at 2003-03-05 14:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify mktime semantics Initial Comment: Python Library Reference, Chapter 6.9 mktime: I believe the C mktime calls ignore the weekday and Julian day values in the tuple. I therefor assume that the Python function also does so, which should be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 From noreply@sourceforge.net Wed Mar 5 13:48:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 05:48:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 14:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Wed Mar 5 14:13:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 06:13:38 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-681533 ] Additional string stuff. Message-ID: Feature Requests item #681533, was opened at 2003-02-06 09:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Additional string stuff. Initial Comment: In a lot of my programs that mess with strings, I end up somewhere making a variable "ascii" via (string.maketrans('', '')). It's just a 256-character string comprising the ascii character set. I use it, oftentimes, simply to be able to turn the 'translate' method on strings into a 'delete' method -- if I want to, say, remove all the spaces in aString, I'd do (aString.translate(ascii, string.whitespace)). Certainly an ascii variable in the string module couldn't hurt, would fit in with ascii_letters, etc. and would at least standarize the name of the full ascii set sure to be present in many Python programs. A little further out there, but I think just as useful, would be a delete method on strings. So "foo bar baz".delete(string.whitespace) would return "foobarbaz". It would be equivalent to "foo bar baz".translate(ascii, string.whitespace), or the wildly inefficient: def delete(s, deleteChars): l = [] for c in s: if c not in deleteChars: l.append(c) return ''.join(l) Anyway, that's all I can think of. Do with it what you will. Jeremy ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 15:13 Message: Logged In: YES user_id=45365 Note that "ascii" is definitely a bad name, as it means different things to anyone. To Python it usually means "7-bit ASCII" (as in the unicode "ascii" codec). To you it apparently means "8-bit something-or-other". I have no opinion on whether this feature is a good idea, but if it is I would suggest a name with "any" or "all" in it, and possibly "8bit" too. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-04 19:25 Message: Logged In: YES user_id=99508 What's the status on this? I checked string.py, and there actually already is a value that's the 256 ASCII characters, but it's called _idmap. Might we consider changing the name of that to "ascii"? I'd be happy to make the patch. Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 07:47 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 06:19 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-07 03:15 Message: Logged In: YES user_id=31435 Just noting that you can pass None for sep if you want to explicitly ask for the default behavior. >>> " a b c".split(None, 1) ['a', 'b c'] >>> ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-06 10:19 Message: Logged In: YES user_id=99508 Let me also make one other suggestion: the split method on a string object has, by default, behavior that can't be replicated by passing an argument as a separator. That is, the default separated acts like re.split(r'\s+'), but it's impossible to pass any value into the method to achieve that same result. The problem arises when a user wants to use the maxsplit() parameter to the method. Because maxsplit is a positional parameter instead of a keyword parameter, the user *must* declare a separate to split on, and thus loses his ability to split on whitespace-in-general. If maxsplit was changed from being a positional parameter to being a keyword parameter, then a programmer wouldn't have to give up the default behavior of the split method in order to pass it a maxsplit. At present, negative maxsplit values don't differ in any way from split's default behavior (with no maxsplit parameter given). Thus, the keyword maxsplit could default to -1 with no breakage of code. I can't see any place where changing maxsplit to a keyword parameter would break any existing code Jeremy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 From noreply@sourceforge.net Wed Mar 5 14:32:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 06:32:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-679520 ] long(3.1415) gives zero on Solaris 8 Message-ID: Bugs item #679520, was opened at 2003-02-03 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679520&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: Works For Me Priority: 5 Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: long(3.1415) gives zero on Solaris 8 Initial Comment: On Solaris 8, running Python 2.2.2, the built-in function long() gave me the following peculiar results when applied to a floating-point argument. (Unfortunately I don't have administrative access to this machine, so couldn't test to see whether Python 2.3a has the same problems.) s0100% uname -a SunOS s0100.math.lsa.umich.edu 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Blade-1000 s0100% python Python 2.2.2 (#22, Dec 23 2002, 12:02:55) [GCC 3.0.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> long(3.1415) 0L >>> _ == 0L 0 >>> long(6e20) 00000000000000000L >>> _ - 1 37778931862957161709567L >>> int(3.1415) 3 ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2003-03-05 14:32 Message: Logged In: YES user_id=703403 This does indeed seem to be a compiler optimization bug; after removing all occurrences of `-O3' from the configure script and rebuilding, the problem disappeared. I guess that it's probably not worth trying to track this problem to its source unless it persists with newer versions of gcc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-07 15:35 Message: Logged In: YES user_id=31435 Python runs on many 64-bit platforms (starting in 1993), so that's not likely a real problem. A compiler optimization bug is much more likely, or perhaps a config problem when compiling Python. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2003-02-07 14:45 Message: Logged In: YES user_id=703403 The sysadmin here is (very helpfully) looking into this; I'll report any findings. I should probably also have pointed out in my original report that this is a 64-bit compile of Python. (Apologies if this is obvious to everyone; it wasn't to me.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-07 01:12 Message: Logged In: YES user_id=33168 Mark, can you verify if this is a compiler problem? I also don't have this problem on a sun? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-02-03 19:41 Message: Logged In: YES user_id=595280 My machine has similar configuration, but works fine; $ uname -a SunOS abbey 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Blade-1000 $ python22 Python 2.2.2 (#1, Oct 15 2002, 14:20:16) [GCC 2.95.3 20010315 (release)] on sunos5 >>> long(3.1415) 3L >>> long(6e20) 600000000000000000000L >>> _ - 1 599999999999999999999L I think it's gcc/glibc optimization issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679520&group_id=5470 From noreply@sourceforge.net Wed Mar 5 15:32:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 07:32:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-684903 ] socket module on solaris Message-ID: Bugs item #684903, was opened at 2003-02-11 22:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=684903&group_id=5470 Category: Build Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: RIck Bradshaw (rabrads) Assigned to: Nobody/Anonymous (nobody) Summary: socket module on solaris Initial Comment: I just built python 2.2.2 on solaris 7 or 2.7 to be technically correct. I then fire up the interpreter and import test.testall. It fails for socket, which is very import to me and my users. I then import _socket and get the following info Python 2.2.2 (#4, Feb 6 2003, 17:17:38) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import _socket Traceback (most recent call last): File "", line 1, in ? ImportError: ld.so.1: /soft/apps/packages/Python-2.2.2/bin/python: fatal: relocation error: file /soft/apps/packages/Python-2.2.2/lib/python2.2/_socket.so: symbol __eprintf: referenced symbol not found Thanks for any help. Rick ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 16:32 Message: Logged In: YES user_id=21627 Most likely, the OpenSSL library was build with gcc. You will need to a) recompile all of Python with gcc, or b) uninstall the OpenSSL library, or c) modify Modules/Setup, to tell Python that the socket module should be built without SSL support. closing as not-a-bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-02-13 09:26 Message: Logged In: YES user_id=29957 This means something didn't get linked with -lgcc. As mwh guessed, this is usually because Solaris' 'ld' was used instead of the GNU one. Does the build machine have a working install of binutils as well as gcc? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-02-12 15:16 Message: Logged In: YES user_id=6656 IIRC this usually happens when you compile with gcc and link with the system ld or vice versa or something like that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-12 00:25 Message: Logged In: YES user_id=33168 This error looks familiar, but I don't recall the cause. Did you have a working version of python on this machine? What compiler and version are you using? Is __eprintf in a library (libc.a)? Is that not getting linked? Is it using the correct linker and library locations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=684903&group_id=5470 From noreply@sourceforge.net Wed Mar 5 15:39:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 07:39:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-679520 ] long(3.1415) gives zero on Solaris 8 Message-ID: Bugs item #679520, was opened at 2003-02-03 09:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679520&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: long(3.1415) gives zero on Solaris 8 Initial Comment: On Solaris 8, running Python 2.2.2, the built-in function long() gave me the following peculiar results when applied to a floating-point argument. (Unfortunately I don't have administrative access to this machine, so couldn't test to see whether Python 2.3a has the same problems.) s0100% uname -a SunOS s0100.math.lsa.umich.edu 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Blade-1000 s0100% python Python 2.2.2 (#22, Dec 23 2002, 12:02:55) [GCC 3.0.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> long(3.1415) 0L >>> _ == 0L 0 >>> long(6e20) 00000000000000000L >>> _ - 1 37778931862957161709567L >>> int(3.1415) 3 ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2003-03-05 09:32 Message: Logged In: YES user_id=703403 This does indeed seem to be a compiler optimization bug; after removing all occurrences of `-O3' from the configure script and rebuilding, the problem disappeared. I guess that it's probably not worth trying to track this problem to its source unless it persists with newer versions of gcc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-07 10:35 Message: Logged In: YES user_id=31435 Python runs on many 64-bit platforms (starting in 1993), so that's not likely a real problem. A compiler optimization bug is much more likely, or perhaps a config problem when compiling Python. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2003-02-07 09:45 Message: Logged In: YES user_id=703403 The sysadmin here is (very helpfully) looking into this; I'll report any findings. I should probably also have pointed out in my original report that this is a 64-bit compile of Python. (Apologies if this is obvious to everyone; it wasn't to me.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 20:12 Message: Logged In: YES user_id=33168 Mark, can you verify if this is a compiler problem? I also don't have this problem on a sun? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-02-03 14:41 Message: Logged In: YES user_id=595280 My machine has similar configuration, but works fine; $ uname -a SunOS abbey 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Blade-1000 $ python22 Python 2.2.2 (#1, Oct 15 2002, 14:20:16) [GCC 2.95.3 20010315 (release)] on sunos5 >>> long(3.1415) 3L >>> long(6e20) 600000000000000000000L >>> _ - 1 599999999999999999999L I think it's gcc/glibc optimization issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679520&group_id=5470 From noreply@sourceforge.net Wed Mar 5 15:40:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 07:40:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule Message-ID: Bugs item #690317, was opened at 2003-02-20 23:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3a2 build fails on Solaris: posixmodule Initial Comment: gcc 2.95.2 SunOS 5.6 sparc gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o In file included from Include/stringobject.h:10, from Include/Python.h:83, from ./Modules/posixmodule.c:16: /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170: warning : redefinition of `va_list' /usr/include/stdio.h:90: warning: `va_list' previously declared here ./Modules/posixmodule.c: In function `posix_access': ./Modules/posixmodule.c:1261: warning: implicit declaration of function `access' ./Modules/posixmodule.c: In function `posix_ttyname': ./Modules/posixmodule.c:1302: warning: implicit declaration of function `ttyname ' ---- --- f' ./Modules/posixmodule.c: In function `posix_confstr': ./Modules/posixmodule.c:6443: warning: implicit declaration of function `confstr ' ./Modules/posixmodule.c: In function `posix_sysconf': ./Modules/posixmodule.c:6985: warning: implicit declaration of function `sysconf ' ./Modules/posixmodule.c: In function `setup_confname_table': ./Modules/posixmodule.c:7024: warning: implicit declaration of function `qsort' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 16:40 Message: Logged In: YES user_id=21627 I find several things confusing in this report: - why is va_list redefined? To my knowledge, gcc 2.95.2 supports Solaris 2.6 correctly, so it shouldn't provide a conflicting va_list definition. The typical cause is that the gcc installation doesn't match the operating system version (i.e. fixincludes was run for different headers). Since the gcc installation appears to have been built for 2.6, I infer that the system being used might not be Solaris 2.6. - All the problems reported are warnings, which don't cause compilation to fail. What is the actual error (use -w to suppress all warnings). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-21 00:08 Message: Logged In: YES user_id=33168 Jeff, I don't know if anyone has access to Solaris 5.6. Can you provide a patch to get posixmodule to compile? From the bug report, I only see warnings, not an actual error which is breaking the build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470 From noreply@sourceforge.net Wed Mar 5 15:42:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 07:42:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: Bugs item #678723, was opened at 2003-02-01 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 16:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-02 02:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 19:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Wed Mar 5 16:25:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 08:25:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-697546 ] Tkinter Help menu error with pythonw Message-ID: Bugs item #697546, was opened at 2003-03-04 22:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Speno (corvus) Assigned to: Jack Jansen (jackjansen) Summary: Tkinter Help menu error with pythonw Initial Comment: Note: Test script attached which demonstrates this problem. If I launch my application using pythonw, then the first item in its 'Help' menu is an extraneous 'x' which I didn't put there, and can't seem to get rid of. Actually, when I first switch to the application, each item in my Help menu is an 'x'. If I switch to another app then back, my menu items have their names back, and there's still the first mysterious 'x'. If I wrap my application up into an applicaiton bundle (foo.app), and run it that way, the menus work as they should. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 17:25 Message: Logged In: YES user_id=45365 After various false starts I found that the automatic enabling of Help menu creation can be disabled by specifying a length 1 array of help books in stead of a single help book. This seems to fix the problem. Checked in as Mac/OSXResources/app/Info.plist rev. 1.9. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 14:04 Message: Logged In: YES user_id=45365 I can repeat this, and I think I know where the problem lies. Unfortunately I don't know how to fix it, yet. Apparently something goes wrong because Python.app (which is used by pythonw) has plist file entries CFBundleHelp*, which cause it to get a help menu. This causes a help menu to be created automatically, which seems to interfere with Tk's own manual creation of a help menu. A workaround is easy: remove those entries from the Python.app plist file and everything is fine. The problem is that I need somewhere to put the Python documentation, and it has to be a .app bundle (that's the only thing AHRegisterHelpBook will accept). That is: I may be able to use a .help bundle, I've come across them. I will investigate, and if this works I'll fix Python.app. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 23:03 Message: Logged In: YES user_id=2138 It doesn't looke like my attachment worked. Here's the script: #!/usr/local/bin/pythonw import Tkinter def hello(): print "hello" root = Tkinter.Tk() root.title('menubar test') menubar = Tkinter.Menu(root) helpmenu = Tkinter.Menu(menubar, name='help', tearoff=0) menubar.add_cascade(label="Help", menu=helpmenu, underline=0) addhelp = helpmenu.add_command addhelp(label='Window Help', underline=0, command=hello, state='normal') addhelp(label='Menu Help', underline=9, command=hello, state='normal') helpmenu.add_separator() addhelp(label='About Assignments', underline=0, command=hello) root.configure(menu=menubar) root.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 From noreply@sourceforge.net Wed Mar 5 16:38:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 08:38:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-697546 ] Tkinter Help menu error with pythonw Message-ID: Bugs item #697546, was opened at 2003-03-04 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Speno (corvus) Assigned to: Jack Jansen (jackjansen) Summary: Tkinter Help menu error with pythonw Initial Comment: Note: Test script attached which demonstrates this problem. If I launch my application using pythonw, then the first item in its 'Help' menu is an extraneous 'x' which I didn't put there, and can't seem to get rid of. Actually, when I first switch to the application, each item in my Help menu is an 'x'. If I switch to another app then back, my menu items have their names back, and there's still the first mysterious 'x'. If I wrap my application up into an applicaiton bundle (foo.app), and run it that way, the menus work as they should. ---------------------------------------------------------------------- >Comment By: John Speno (corvus) Date: 2003-03-05 11:38 Message: Logged In: YES user_id=2138 Thanks. That fix works for me also. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 11:25 Message: Logged In: YES user_id=45365 After various false starts I found that the automatic enabling of Help menu creation can be disabled by specifying a length 1 array of help books in stead of a single help book. This seems to fix the problem. Checked in as Mac/OSXResources/app/Info.plist rev. 1.9. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 08:04 Message: Logged In: YES user_id=45365 I can repeat this, and I think I know where the problem lies. Unfortunately I don't know how to fix it, yet. Apparently something goes wrong because Python.app (which is used by pythonw) has plist file entries CFBundleHelp*, which cause it to get a help menu. This causes a help menu to be created automatically, which seems to interfere with Tk's own manual creation of a help menu. A workaround is easy: remove those entries from the Python.app plist file and everything is fine. The problem is that I need somewhere to put the Python documentation, and it has to be a .app bundle (that's the only thing AHRegisterHelpBook will accept). That is: I may be able to use a .help bundle, I've come across them. I will investigate, and if this works I'll fix Python.app. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 17:03 Message: Logged In: YES user_id=2138 It doesn't looke like my attachment worked. Here's the script: #!/usr/local/bin/pythonw import Tkinter def hello(): print "hello" root = Tkinter.Tk() root.title('menubar test') menubar = Tkinter.Menu(root) helpmenu = Tkinter.Menu(menubar, name='help', tearoff=0) menubar.add_cascade(label="Help", menu=helpmenu, underline=0) addhelp = helpmenu.add_command addhelp(label='Window Help', underline=0, command=hello, state='normal') addhelp(label='Menu Help', underline=9, command=hello, state='normal') helpmenu.add_separator() addhelp(label='About Assignments', underline=0, command=hello) root.configure(menu=menubar) root.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697546&group_id=5470 From noreply@sourceforge.net Wed Mar 5 18:49:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 10:49:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Jim Murff (jmurff) Date: 2003-03-05 10:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 18:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 17:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 5 19:05:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 11:05:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-697989 ] Clarify mktime semantics Message-ID: Bugs item #697989, was opened at 2003-03-05 08:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify mktime semantics Initial Comment: Python Library Reference, Chapter 6.9 mktime: I believe the C mktime calls ignore the weekday and Julian day values in the tuple. I therefor assume that the Python function also does so, which should be documented. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-05 14:05 Message: Logged In: YES user_id=31435 Python does (for the most part) inherit mktime semantics from the platform C, but mktime() is "underspecified" by ANSI C and there's little that can be said about oddball cases across platforms. Sometimes it even depends on the preprocessor symbols defined when the platform C library was compiled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 From noreply@sourceforge.net Wed Mar 5 19:41:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 11:41:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 5 20:09:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 12:09:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-26 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-05 13:09 Message: Logged In: YES user_id=85984 Your test indeed does make the hang go away, thanks. I guess I'll turn my efforts to qmail. Since this doesn't seem like a Python problem, feel free to close this out. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 13:45 Message: Logged In: YES user_id=45365 That confirms my suspicion that this is a third-party error: filedescriptors 2 and 3 are readwrite on BSD, write-only on Linux. A final test to confirm this: on BSD, add code like this just before calling popen(): os.close(1) os.close(2) os.open("/dev/null", "w") os.open("/dev/null", "w") If this makes the hang go away then the real problem is that whatever program executes your .forward (qmail?) erroneously opens a read-write pipe for your stdout and stderr. You can't do this with pipe() AFAIK, but maybe with socketpair() or something. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-04 11:45 Message: Logged In: YES user_id=85984 Attached is lsof output on a Linux box. I had to insert a sleep after the write but before the close in order to capture it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 03:33 Message: Logged In: YES user_id=45365 Something like fstat is indeed what I was suggesting. The fstat output shows your Python script is getting stdin from a file, and stdout/stderr go to a pipe (the same one). You also have another pip open on filedescriptors 3/4. Try the same thing on Linux (or another system where things just work) and see if there's a difference in what files are open. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-03 13:05 Message: Logged In: YES user_id=85984 > Try finding out what stdin/stdout/stderr refer to > (with fstat or something). Can you be more specific here? I've attached the output of `fstat -m -p 15437' below in case that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 03:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Wed Mar 5 20:43:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 12:43:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 15:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 5 20:52:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 12:52:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-698282 ] __file__ attribute missing from dynamicly loaded module Message-ID: Bugs item #698282, was opened at 2003-03-05 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698282&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David C. Sweeton (dsweeton) Assigned to: Nobody/Anonymous (nobody) Summary: __file__ attribute missing from dynamicly loaded module Initial Comment: Only the first instanceof a dynamically loaded module gets the __file__ attribute. It is missing from all later instances. The problem is in importdl.c in the function _PyImport_LoadDynamicModule. The first time a module is loaded a copy of its module dictionary is made by a call to _PyImport_FixupExtension. After that copy was made, _PyImport_LoadDynamicModule adds the _file__ attribute to the original module dictionary. Thus the first instance of the module has the __file__attribute. Later when another instance of the module loads, its module dictionary is duplicated from the copy of the dictionary from the first instance. The problem is that when that copy was made, the __file__ attribute was not yet there. Thus the later instance of the module does not have the __file__ attribute. The required fix is in importdl.c and consists of simply moving the call of _PyImport_FixupExtension to a point just after the __file__ attribute is added, instead of just before it. I have tested this fix and it solves the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698282&group_id=5470 From noreply@sourceforge.net Wed Mar 5 21:03:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 13:03:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Wed Mar 5 21:09:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 13:09:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-694062 ] os.popen() hangs on {Free,Open}BSD Message-ID: Bugs item #694062, was opened at 2003-02-27 02:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 Category: Python Interpreter Core >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen() hangs on {Free,Open}BSD Initial Comment: I'm seeing odd behavior with os.popen() on certain platforms such as FreeBSD and OpenBSD. FWIW, I posted about this problem almost two years ago on c.l.p, and never got a resolution. See http://mail.python.org/pipermail/python-list/2001-May/042373.html Now, many Python and FreeBSD upgrades later, I see the problem still exists. Now however, I need to find a solution as I can't workaround it any longer. I've attached about the simplest test case I could produce below. You can call it from a .forward or .qmail file. On Free/OpenBSD, the program runs but leaves a python process lying around: jasonrm 142 0.0 0.2 2576 2008 ?? I 5:42PM 0:00.02 python /tmp/hang (python2.2) On other platforms such as Linux, the program also runs, but no process is left hanging around. I've been able to reproduce the problem on Free/OpenBSD only. The problem doesn't appear on IRIX, BSD/OS or Linux. Please let me know if I can do anything more to help debug this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-05 21:09 Message: Logged In: YES user_id=85984 Your test indeed does make the hang go away, thanks. I guess I'll turn my efforts to qmail. Since this doesn't seem like a Python problem, feel free to close this out. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 21:45 Message: Logged In: YES user_id=45365 That confirms my suspicion that this is a third-party error: filedescriptors 2 and 3 are readwrite on BSD, write-only on Linux. A final test to confirm this: on BSD, add code like this just before calling popen(): os.close(1) os.close(2) os.open("/dev/null", "w") os.open("/dev/null", "w") If this makes the hang go away then the real problem is that whatever program executes your .forward (qmail?) erroneously opens a read-write pipe for your stdout and stderr. You can't do this with pipe() AFAIK, but maybe with socketpair() or something. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-04 19:45 Message: Logged In: YES user_id=85984 Attached is lsof output on a Linux box. I had to insert a sleep after the write but before the close in order to capture it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-04 11:33 Message: Logged In: YES user_id=45365 Something like fstat is indeed what I was suggesting. The fstat output shows your Python script is getting stdin from a file, and stdout/stderr go to a pipe (the same one). You also have another pip open on filedescriptors 3/4. Try the same thing on Linux (or another system where things just work) and see if there's a difference in what files are open. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-03-03 21:05 Message: Logged In: YES user_id=85984 > Try finding out what stdin/stdout/stderr refer to > (with fstat or something). Can you be more specific here? I've attached the output of `fstat -m -p 15437' below in case that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-03 11:57 Message: Logged In: YES user_id=45365 Just for fun I tried it on MacOSX, but running from the shall, not qmail, and I don't see any problems there. At least, not if I pass a small input message. If I pass a large input message I get a "broken pipe", but that is to be expected (as true doesn't really read it's input). My guess is that this is a third-party error, somehow related to how qmail sets up stdin/stdout/stderr (apparently slightly different on Free/OpenBSD and the other systems). Try finding out what stdin/stdout/stderr refer to (with fstat or something). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694062&group_id=5470 From noreply@sourceforge.net Wed Mar 5 21:57:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 13:57:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:57 Message: Logged In: YES user_id=454042 We don't see the problem in Python 2.1. In fact initially we fell back to 2.1 but I don't want to stay there. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 12:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 11:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 10:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 18:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 17:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 5 23:46:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 15:46:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-698374 ] urllib2 Request.get_host and proxies Message-ID: Bugs item #698374, was opened at 2003-03-05 23:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698374&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 Request.get_host and proxies Initial Comment: I think the Request.get_host method should not return the host of the proxy in the case where a proxy has been set. There should be a separate method for returning the proxy's hostname. I'm baffled as to why someone thought a request's host is its proxy's host! Am I missing something? Note that this bug is related to 413135 -- should both be fixed simultaneously. I'll upload a patch eventually. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698374&group_id=5470 From noreply@sourceforge.net Wed Mar 5 23:52:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 15:52:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-413135 ] urllib2 fails with proxy requiring auth Message-ID: Bugs item #413135, was opened at 2001-04-02 15:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413135&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Moshe Zadka (moshez) Summary: urllib2 fails with proxy requiring auth Initial Comment: The following program: import urllib2 proxy_info = { 'user' : 'my_name', 'pass' : 'my_pass', 'host' : "my-proxy", 'port' : 80 } # build a new opener that uses a proxy requiring # authorization proxy_support = urllib2.ProxyHandler( {"http" : "http://%(user)s:%(pass)s@%(host)s:%(port)d" % proxy_info}) opener = urllib2.build_opener(proxy_support, urllib2.HTTPHandler) # install it urllib2.install_opener(opener) f = urllib2.urlopen('http://www.python.org/') print f.headers print f.read() fails with the following error on Python 2.1b2 (on Windows) C:\Data>python21 proxy_auth.py Traceback (most recent call last): File "proxy_auth.py", line 18, in ? f = urllib2.urlopen('http://www.python.org/') File "c:\applications\python21\lib\urllib2.py", line 135, in urlopen return _opener.open(url, data) File "c:\applications\python21\lib\urllib2.py", line 318, in open '_open', req) File "c:\applications\python21\lib\urllib2.py", line 297, in _call_chain result = func(*args) File "c:\applications\python21\lib\urllib2.py", line 823, in http_open return self.do_open(httplib.HTTP, req) File "c:\applications\python21\lib\urllib2.py", line 801, in do_open raise URLError(err) urllib2.URLError: A similar error occurred in beta 1, but this was reported as bug 406683. The fix is in beta 2. I applied the fix manually in beta 1, and it worked, so I can only assume that something else changed in the transition from beta 1 to beta 2, which broke this again. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 23:52 Message: Logged In: YES user_id=261020 Just a note that bug 698374 is related, and should be fixed at the same time as this one. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-02-12 20:45 Message: Logged In: YES user_id=261020 Well, I believe Paul when he says his proxy was doing this, but AFAICS, RFC 2616 says this is incorrect: (RFC 2616, p. 128): The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address. Can't find anything to say this doesn't apply to requests going via a proxy. Of course (well, I say of course -- I *think* I understand fully), the Host: header is redundant for proxies, because you have to send the full absoluteURI (with host) anyway, but I think Python should follow the RFC rather some random, and presumably broken, proxy. [well, to clarify: Host is redundant when using a proxy, but still required to be present by the RFC -- don't know why] BTW, urllib.py (in 2.2.1, anyway) *does* still follow RFC 2616, so urllib now differs from Moshe's 'fixed' urllib2. I think the patch to urllib2 should be reversed. John ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-11 08:45 Message: Logged In: YES user_id=11645 You're right! I've fixed this in urllib2.py v 1.12 ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-04-10 10:46 Message: Logged In: YES user_id=113328 I found the problem. In urllib2.py, class AbstractHTTPHandler, method do_open, the first line is now host = urlparse.urlparse(req.get_full_url())[1] It used to be host = req.get_host() With the old version, the code works (with my proxy). With the new version it doesn't, as it passes the destination host, rather than the proxy name (and so loses the proxy info totally). Paul. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2001-04-10 10:45 Message: Logged In: YES user_id=113328 I found the problem. In urllib2.py, class AbstractHTTPHandler, method do_open, the first line is now host = urlparse.urlparse(req.get_full_url())[1] It used to be host = req.get_host() With the old version, the code works (with my proxy). With the new version it doesn't, as it passes the destination host, rather than the proxy name (and so loses the proxy info totally). Paul. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-09 15:11 Message: Logged In: YES user_id=11645 I've just tested with my installation of Python 2.1b2 and it works. So I cannot reproduce the problem, and I need more information from you: can you insert prints in the correct places (e.g. do_open) to see what host urllib2 *thinks* it is trying to access? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413135&group_id=5470 From noreply@sourceforge.net Thu Mar 6 03:03:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 19:03:12 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-681533 ] Additional string stuff. Message-ID: Feature Requests item #681533, was opened at 2003-02-06 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Additional string stuff. Initial Comment: In a lot of my programs that mess with strings, I end up somewhere making a variable "ascii" via (string.maketrans('', '')). It's just a 256-character string comprising the ascii character set. I use it, oftentimes, simply to be able to turn the 'translate' method on strings into a 'delete' method -- if I want to, say, remove all the spaces in aString, I'd do (aString.translate(ascii, string.whitespace)). Certainly an ascii variable in the string module couldn't hurt, would fit in with ascii_letters, etc. and would at least standarize the name of the full ascii set sure to be present in many Python programs. A little further out there, but I think just as useful, would be a delete method on strings. So "foo bar baz".delete(string.whitespace) would return "foobarbaz". It would be equivalent to "foo bar baz".translate(ascii, string.whitespace), or the wildly inefficient: def delete(s, deleteChars): l = [] for c in s: if c not in deleteChars: l.append(c) return ''.join(l) Anyway, that's all I can think of. Do with it what you will. Jeremy ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-05 22:03 Message: Logged In: YES user_id=99508 Ah, yes, you're right. I never knew ASCII was only 7 bits per character. Perhaps string.all_characters? I just definitely think it should be publically available so there can be some consistency between applications that need a string of all 256 8-bit characters. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 09:13 Message: Logged In: YES user_id=45365 Note that "ascii" is definitely a bad name, as it means different things to anyone. To Python it usually means "7-bit ASCII" (as in the unicode "ascii" codec). To you it apparently means "8-bit something-or-other". I have no opinion on whether this feature is a good idea, but if it is I would suggest a name with "any" or "all" in it, and possibly "8bit" too. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-04 13:25 Message: Logged In: YES user_id=99508 What's the status on this? I checked string.py, and there actually already is a value that's the 256 ASCII characters, but it's called _idmap. Might we consider changing the name of that to "ascii"? I'd be happy to make the patch. Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 01:47 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 00:19 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-06 21:15 Message: Logged In: YES user_id=31435 Just noting that you can pass None for sep if you want to explicitly ask for the default behavior. >>> " a b c".split(None, 1) ['a', 'b c'] >>> ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-06 04:19 Message: Logged In: YES user_id=99508 Let me also make one other suggestion: the split method on a string object has, by default, behavior that can't be replicated by passing an argument as a separator. That is, the default separated acts like re.split(r'\s+'), but it's impossible to pass any value into the method to achieve that same result. The problem arises when a user wants to use the maxsplit() parameter to the method. Because maxsplit is a positional parameter instead of a keyword parameter, the user *must* declare a separate to split on, and thus loses his ability to split on whitespace-in-general. If maxsplit was changed from being a positional parameter to being a keyword parameter, then a programmer wouldn't have to give up the default behavior of the split method in order to pass it a maxsplit. At present, negative maxsplit values don't differ in any way from split's default behavior (with no maxsplit parameter given). Thus, the keyword maxsplit could default to -1 with no breakage of code. I can't see any place where changing maxsplit to a keyword parameter would break any existing code Jeremy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 From noreply@sourceforge.net Thu Mar 6 05:52:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 21:52:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-698517 ] Tk 8.4.2 and Tkinter.py _substitue function Message-ID: Bugs item #698517, was opened at 2003-03-06 00:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698517&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: Tk 8.4.2 and Tkinter.py _substitue function Initial Comment: In Tk 8.4.2 (out now, or RSN), a change was made to events. From Tk's ChangeLog: * generic/tkBind.c (ExpandPercents): Only allow events to see those expansions that are actually valid for them, and force the substitution of the rest as "??". This stops some crashes on Windows and gets rid of bogus values everywhere. [Bug #612110] Thus, Tkinter.py's _substitue method of Class Misc will need all of it's called to getint() (aka int()) wrapped to catch ValueErrors because the argument could now be '??' instead of something int()'able. Does that make sense? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698517&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:25:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:25:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch Message-ID: Bugs item #697220, was opened at 2003-03-04 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Gerhard Häring (ghaering) Summary: string.strip implementation/doc mismatch Initial Comment: #v+ >>> "test".strip("t") 'es' >>> import string >>> print string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> #v- *But* the Python documentation says that not only the string *method* strip() will allow a second optional argument, but also the strip function in the string module. (http://www.python.org/doc/current/lib/module-string.html) string.strip should be changed to accept the additional parameter. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:25 Message: Logged In: YES user_id=33168 Gerhard, hopefully I've cleaned things up this time. Could you review both patches attached (one for 2.2.3, the other for 2.3)? I will send a message to python-dev to get concurrence on the changes and hopefully more review. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-04 13:20 Message: Logged In: YES user_id=33168 Thanks, you are correct. The problem was with the string object, not the string module. :-( I need to look at this more. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2003-03-04 13:10 Message: Logged In: YES user_id=163326 Neil, I don't think this was implemented in the 2.2 maintenance branch. That's why I'm reopening this. At least for my 2.2 Pythons string.strip accepts one parameter only: 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 string >>> string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) >>> and Python 2.2.2 (#1, Feb 9 2003, 13:22:07) [GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> string.strip("test", "t") Traceback (most recent call last): File "", line 1, in ? TypeError: strip() takes exactly 1 argument (2 given) Confused. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-04 12:55 Message: Logged In: YES user_id=33168 Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before do not. We should really update the doc. I thought this was done, but apparently not. Checked in as: libstring.tex 1.45.8.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:26:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:26:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-697556 ] test_posix fails: getlogin Message-ID: Bugs item #697556, was opened at 2003-03-04 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_posix fails: getlogin Initial Comment: I see bug #690081 made this run only in interactive mode, but it still fails for me when I do a make test. Apparently my utmp is in an unexpected place, /var/run/, which I guess doesn't agree with my libc? I don't know how common this bug will be for other people, but if anyone else experiences it you should probably just get rid of the getlogin test altogether, or at least catch the OSError: (2, 'No such file or directory') and don't have that mean test failure. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:26 Message: Logged In: YES user_id=33168 I'll take a look at this soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:26:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:26:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-675420 ] email.Header() encoding does not work properly Message-ID: Bugs item #675420, was opened at 2003-01-27 08:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header() encoding does not work properly Initial Comment: CMFCollectorNG uses email.Header() to encode the Subject of notification emails. In some case we discovered that Evolution and Mutt displayed an empty subject. The Subject "[CMFCollectorNG] #31 (Comment): noch: ein test" is converted to Subject: =?iso-8859-1?q?=5BCMFCollectorNG=5D_=2331_=28Comment=29=3A_ein=3A_test?= The problem seems to occur if there is more than one colon inside the subject. Mailings with "[CMFCollectorNG] #31 (Comment): noch ein test" as subject are recognized by the mail readers and being displayed. Upgrading to the latest email packages from the Python HEAD did not solve the problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:26 Message: Logged In: YES user_id=12800 I don't understand. Where's the email package error? It seems like you're complaining about some MUA bugs. Can you upload (not paste) a Python code sample that illustrates the bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:28:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:28:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-697256 ] PyMarshal_WriteShortToFile() documented, but not implemented Message-ID: Bugs item #697256, was opened at 2003-03-04 08:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) >Assigned to: Guido van Rossum (gvanrossum) Summary: PyMarshal_WriteShortToFile() documented, but not implemented Initial Comment: $ grep -r PyMarshal_WriteShortToFile * Doc/api/utilities.tex:\begin{cfuncdesc}{void}{PyMarshal_WriteShortToFile}{short value, FILE *file} Include/marshal.h:PyAPI_FUNC(void) PyMarshal_WriteShortToFile(int, FILE *); I guess it is a historic function that was removed at some point? Appears in both Python 2.2.2 and 2.3a2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:28 Message: Logged In: YES user_id=33168 Guido, any problem removing the doc and prototype? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:31:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:31:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary Message-ID: Bugs item #667931, was opened at 2003-01-14 13:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: BoundaryError: multipart message with no defined boundary Initial Comment: More problems with the email package raising exceptions when trying to parse non-compliant messages. Even when lax parsing is enabled, a BoundaryError is raised when trying to parse the attached spam message. I'd like to see some sort of workaround to handle these cases more gracefully when when lax parsing is enabled. This behavior seems like 'strict' parsing behavior to me. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:31 Message: Logged In: YES user_id=12800 I see what you're saying, Jason, but I don't know how Parser could do much better. You can always fall back to email.Header.HeaderParser when all else fails (well all else modulo severely broken headers). ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-02-20 14:33 Message: Logged In: YES user_id=85984 As Python 2.3a2 was just released, I'm worried that this one is going to fall through the cracks before 2.3-final is released which would be unfortunate because it would mean I'd have to continue bundling my own copy of email with my applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:50:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:50:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-640110 ] email.Header misparses mixed headers Message-ID: Bugs item #640110, was opened at 2002-11-18 09:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anders Hammarquist (iko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header misparses mixed headers Initial Comment: email.Header.decode_header() misparses headers with both encoded an unencoded words. This example from RFC2047 =?ISO-8859-1?Q?Andr=E9?= Pirard gets parsed as AndréPirard where there should obviously be a space between André and Pirard. RFC2047 says to ignore spaces between encoded words (but not between encoded and unencoded words, though it doesn't explicitly say so from what I could find, and obviously not between unencoded words). Also, I see it's trying to handle continuation lines, but it only does it if there are encoded words in the continuation line. It barfs badly on this test case: 'Re: =?mac-iceland?q?r=8Aksm=9Arg=8Cs?= baz\n foo bar =?mac-iceland?q?r=8Aksm=9Arg=8Cs?=' I think I'll just do a patch... /Anders P.S. It seems at least remotely related to Bug#552957 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:50 Message: Logged In: YES user_id=12800 The first bug above has already been fixed in email 2.5 (python 2.3 cvs). The second pointed to a real bug, now fixed I believe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 From noreply@sourceforge.net Thu Mar 6 06:57:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 05 Mar 2003 22:57:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-633550 ] HeaderParseError: no header value Message-ID: Bugs item #633550, was opened at 2002-11-04 18: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: Closed >Resolution: Out of Date 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. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:57 Message: Logged In: YES user_id=12800 When I run the referenced message (well, the subpart with the broken header) through current Python2.3cvs's Parser, I get a message where the line "content_id=xmailer_a0" is the first line of the body. We changed Parser so that in lax mode, the first non-header like line (not necessarily a blank line) stops the header parsing. Since this seems as reasonable as anything else in this case, I'm closing this bug report. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-02-20 14:33 Message: Logged In: YES user_id=85984 As Python 2.3a2 was just released, I'm worried that this one is going to fall through the cracks before 2.3-final is released which would be unfortunate because it would mean I'd have to continue bundling my own copy of email with my applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633550&group_id=5470 From noreply@sourceforge.net Thu Mar 6 08:27:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 00:27:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-690214 ] robotparser only applies first applicable rule Message-ID: Bugs item #690214, was opened at 2003-02-20 12:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690214&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mark Pilgrim (f8dy) Assigned to: Skip Montanaro (montanaro) Summary: robotparser only applies first applicable rule Initial Comment: robotparser robotparser.py::RobotFileParser::can_fetch currently returns the result of the first applicable rule. It should loop through all rules looking for anything that disallows access. For example, if your first rule applies to 'wget' and 'python' and disallows access to /dir1/, and your second rule is a 'python' rule that disallows access to /dir2/, robotparser will falsely claim that python is allowed to access /dir2/. Patch against current source attached. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-03-06 02:27 Message: Logged In: YES user_id=44345 Closing as it appears robotparser's behavior matches the rfc as Bastian indicated. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2003-03-03 05:46 Message: Logged In: YES user_id=9205 Mark, if you dive into http://www.robotstxt.org/wc/norobots-rfc.txt you'll note that the first matching user-agent line as well as the first matching allow or disallow line must be obeyed by the robot (see 3.2.1 and 3.2.2). Now, I am not opposed to disobey the above rfc, but there are other arguments against your patch: a) it breaks current implementations of robots.txt (potentially disallowing access to sites) b) your problem is easily solved by moving Disallow and/or User-Agent lines to the top Therefore my count is -1 for this patch. Cheers, Bastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690214&group_id=5470 From noreply@sourceforge.net Thu Mar 6 08:50:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 00:50:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-698561 ] list.index() bhvr change > python2.x Message-ID: Bugs item #698561, was opened at 2003-03-06 19:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Wittfoth (wittfoth) Assigned to: Nobody/Anonymous (nobody) Summary: list.index() bhvr change > python2.x Initial Comment: #!/usr/bin/python """ Between python1.x and python2.x there has been a major undocumented (?) change in the behaviour of list.index(). (At least I have been unable to locate the relevant PEP.) The following snippet illustrates this problem, though the error was encountered in a more complex real world situation, where a prototype system developed under python1.52 is being realised in python2.2.2. """ class Order : def __init__ (self, ordernum) : self.num = ordernum def __eq__ (self, other) : if (hasattr(other, 'num')) : return self.num == other.num else : return self is other if __name__ == '__main__' : a = Order(123) b = Order(234) c = Order(345) d = Order(123) orders = [a, b, c, d] for o in orders : print orders.index(o) """ Under python1.4 (Solaris 5.6) and python1.52 (Linux 2.4.x) the output is as would be expected : 0 1 2 3 Under python2.1.1, python2.2.2 and python2.3a2 (all Linux 2.4.x),the output is : 0 1 2 0 >From python2.x, list.index() apparently tests for equivalence rather than for identity. This is wrong, not the least because it breaks existing code (and more importantly, existing design). More fundamentally the problem is that it makes dangerous the use of the __eq__ hook, to redefine object equivalence, and contravenes the 'principle of least surprise.' As far as I know, testing for identity (is) cannot be overriden, whereas testing for equivalence (==) can. That being the case it is clearly safer to hang list.index() on the fixed nature of identity, rather than the redefinable nature of equivalence. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 From noreply@sourceforge.net Thu Mar 6 13:10:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 05:10:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-697256 ] PyMarshal_WriteShortToFile() documented, but not implemented Message-ID: Bugs item #697256, was opened at 2003-03-04 08:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) >Assigned to: Neal Norwitz (nnorwitz) Summary: PyMarshal_WriteShortToFile() documented, but not implemented Initial Comment: $ grep -r PyMarshal_WriteShortToFile * Doc/api/utilities.tex:\begin{cfuncdesc}{void}{PyMarshal_WriteShortToFile}{short value, FILE *file} Include/marshal.h:PyAPI_FUNC(void) PyMarshal_WriteShortToFile(int, FILE *); I guess it is a historic function that was removed at some point? Appears in both Python 2.2.2 and 2.3a2. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-06 08:10 Message: Logged In: YES user_id=6380 Go ahead! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:28 Message: Logged In: YES user_id=33168 Guido, any problem removing the doc and prototype? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 From noreply@sourceforge.net Thu Mar 6 13:45:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 05:45:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-698706 ] imaplib: parsing INTERNALDATE Message-ID: Bugs item #698706, was opened at 2003-03-06 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib: parsing INTERNALDATE Initial Comment: The regular expression InternalDate in imaplib does not match dates in which the day number is two-digit with a leading zero. >From a cursory glance at the IMAP definition, this is a legal format, and there is at least one IMAP server that uses it (courier-imap). The attached patch is for Python 2.2.2, but the problem still exists in 2.3a2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 From noreply@sourceforge.net Thu Mar 6 14:15:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 06:15:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-640110 ] email.Header misparses mixed headers Message-ID: Bugs item #640110, was opened at 2002-11-18 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Anders Hammarquist (iko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header misparses mixed headers Initial Comment: email.Header.decode_header() misparses headers with both encoded an unencoded words. This example from RFC2047 =?ISO-8859-1?Q?Andr=E9?= Pirard gets parsed as AndréPirard where there should obviously be a space between André and Pirard. RFC2047 says to ignore spaces between encoded words (but not between encoded and unencoded words, though it doesn't explicitly say so from what I could find, and obviously not between unencoded words). Also, I see it's trying to handle continuation lines, but it only does it if there are encoded words in the continuation line. It barfs badly on this test case: 'Re: =?mac-iceland?q?r=8Aksm=9Arg=8Cs?= baz\n foo bar =?mac-iceland?q?r=8Aksm=9Arg=8Cs?=' I think I'll just do a patch... /Anders P.S. It seems at least remotely related to Bug#552957 ---------------------------------------------------------------------- >Comment By: Anders Hammarquist (iko) Date: 2003-03-06 15:15 Message: Logged In: YES user_id=14 The first bug is still there... With version 1.19 from CVS I get this with my example: >>> print unicode(Header.make_header(Header.decode_header('=?ISO-8859-1?Q?Andr=E9?= Pirard '))).encode('latin-1') AndréPirard (The problem is that whitespaces get stripped of on line 91: unenc = parts.pop(0).strip() before we know whether they are significant or not. The continuation line bug seems to be fixed however. /Anders ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 07:50 Message: Logged In: YES user_id=12800 The first bug above has already been fixed in email 2.5 (python 2.3 cvs). The second pointed to a real bug, now fixed I believe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 From noreply@sourceforge.net Thu Mar 6 15:44:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 07:44:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-697989 ] Clarify mktime semantics Message-ID: Bugs item #697989, was opened at 2003-03-05 14:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify mktime semantics Initial Comment: Python Library Reference, Chapter 6.9 mktime: I believe the C mktime calls ignore the weekday and Julian day values in the tuple. I therefor assume that the Python function also does so, which should be documented. ---------------------------------------------------------------------- >Comment By: Erland Lewin (erl) Date: 2003-03-06 16:44 Message: Logged In: YES user_id=116933 I have a draft of the C99 standard, which in paragraph 7.23.2.3 describes mktime, and says: "The original values of the tm_wday and tm_yday components of the structure are ignored..." So, I would say that mktime() is *not* underspecified by ISO C. In order to write correct programs, it is neccessary to know the semantics of the functions, and IMHO the manual should specify what can be expected of them. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-05 20:05 Message: Logged In: YES user_id=31435 Python does (for the most part) inherit mktime semantics from the platform C, but mktime() is "underspecified" by ANSI C and there's little that can be said about oddball cases across platforms. Sometimes it even depends on the preprocessor symbols defined when the platform C library was compiled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 From noreply@sourceforge.net Thu Mar 6 16:21:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 08:21:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-640110 ] email.Header misparses mixed headers Message-ID: Bugs item #640110, was opened at 2002-11-18 09:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Anders Hammarquist (iko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header misparses mixed headers Initial Comment: email.Header.decode_header() misparses headers with both encoded an unencoded words. This example from RFC2047 =?ISO-8859-1?Q?Andr=E9?= Pirard gets parsed as AndréPirard where there should obviously be a space between André and Pirard. RFC2047 says to ignore spaces between encoded words (but not between encoded and unencoded words, though it doesn't explicitly say so from what I could find, and obviously not between unencoded words). Also, I see it's trying to handle continuation lines, but it only does it if there are encoded words in the continuation line. It barfs badly on this test case: 'Re: =?mac-iceland?q?r=8Aksm=9Arg=8Cs?= baz\n foo bar =?mac-iceland?q?r=8Aksm=9Arg=8Cs?=' I think I'll just do a patch... /Anders P.S. It seems at least remotely related to Bug#552957 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 11:21 Message: Logged In: YES user_id=12800 Try current cvs. ---------------------------------------------------------------------- Comment By: Anders Hammarquist (iko) Date: 2003-03-06 09:15 Message: Logged In: YES user_id=14 The first bug is still there... With version 1.19 from CVS I get this with my example: >>> print unicode(Header.make_header(Header.decode_header('=?ISO-8859-1?Q?Andr=E9?= Pirard '))).encode('latin-1') AndréPirard (The problem is that whitespaces get stripped of on line 91: unenc = parts.pop(0).strip() before we know whether they are significant or not. The continuation line bug seems to be fixed however. /Anders ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:50 Message: Logged In: YES user_id=12800 The first bug above has already been fixed in email 2.5 (python 2.3 cvs). The second pointed to a real bug, now fixed I believe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 From noreply@sourceforge.net Thu Mar 6 16:43:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 08:43:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-640110 ] email.Header misparses mixed headers Message-ID: Bugs item #640110, was opened at 2002-11-18 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Anders Hammarquist (iko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header misparses mixed headers Initial Comment: email.Header.decode_header() misparses headers with both encoded an unencoded words. This example from RFC2047 =?ISO-8859-1?Q?Andr=E9?= Pirard gets parsed as AndréPirard where there should obviously be a space between André and Pirard. RFC2047 says to ignore spaces between encoded words (but not between encoded and unencoded words, though it doesn't explicitly say so from what I could find, and obviously not between unencoded words). Also, I see it's trying to handle continuation lines, but it only does it if there are encoded words in the continuation line. It barfs badly on this test case: 'Re: =?mac-iceland?q?r=8Aksm=9Arg=8Cs?= baz\n foo bar =?mac-iceland?q?r=8Aksm=9Arg=8Cs?=' I think I'll just do a patch... /Anders P.S. It seems at least remotely related to Bug#552957 ---------------------------------------------------------------------- >Comment By: Anders Hammarquist (iko) Date: 2003-03-06 17:43 Message: Logged In: YES user_id=14 Looks OK. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 17:21 Message: Logged In: YES user_id=12800 Try current cvs. ---------------------------------------------------------------------- Comment By: Anders Hammarquist (iko) Date: 2003-03-06 15:15 Message: Logged In: YES user_id=14 The first bug is still there... With version 1.19 from CVS I get this with my example: >>> print unicode(Header.make_header(Header.decode_header('=?ISO-8859-1?Q?Andr=E9?= Pirard '))).encode('latin-1') AndréPirard (The problem is that whitespaces get stripped of on line 91: unenc = parts.pop(0).strip() before we know whether they are significant or not. The continuation line bug seems to be fixed however. /Anders ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 07:50 Message: Logged In: YES user_id=12800 The first bug above has already been fixed in email 2.5 (python 2.3 cvs). The second pointed to a real bug, now fixed I believe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640110&group_id=5470 From noreply@sourceforge.net Thu Mar 6 18:45:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 10:45:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-698900 ] Provide "plucker" format docs. Message-ID: Bugs item #698900, was opened at 2003-03-06 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698900&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Provide "plucker" format docs. Initial Comment: There have been a few requests for documents to be provided in the "plucker" format for use on PDAs. Plucker has the adantage of being free software (both in terms of liberty and price), whereas iSilo is merely low-priced (free in some flavors?). Information on Plucker can be found at www.plkr.org. Documentation for the conversion tool appears slim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698900&group_id=5470 From noreply@sourceforge.net Thu Mar 6 19:01:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 11:01:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-697989 ] Clarify mktime semantics Message-ID: Bugs item #697989, was opened at 2003-03-05 08:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify mktime semantics Initial Comment: Python Library Reference, Chapter 6.9 mktime: I believe the C mktime calls ignore the weekday and Julian day values in the tuple. I therefor assume that the Python function also does so, which should be documented. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-06 14:01 Message: Logged In: YES user_id=31435 Yup, I agree the spec is clear on this specific point. I'd rather the docs refer users to the platform C docs, though, as many other aspects of mktime can and do vary across implementations (for example, C is silent on the origin of the epoch, while POSIX defines it; C and POSIX are both clear as mud about how out-of-range struct tm members are to be treated; etc -- google for mktime man pages to see what a mess this function really is across platforms). ---------------------------------------------------------------------- Comment By: Erland Lewin (erl) Date: 2003-03-06 10:44 Message: Logged In: YES user_id=116933 I have a draft of the C99 standard, which in paragraph 7.23.2.3 describes mktime, and says: "The original values of the tm_wday and tm_yday components of the structure are ignored..." So, I would say that mktime() is *not* underspecified by ISO C. In order to write correct programs, it is neccessary to know the semantics of the functions, and IMHO the manual should specify what can be expected of them. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-05 14:05 Message: Logged In: YES user_id=31435 Python does (for the most part) inherit mktime semantics from the platform C, but mktime() is "underspecified" by ANSI C and there's little that can be said about oddball cases across platforms. Sometimes it even depends on the preprocessor symbols defined when the platform C library was compiled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697989&group_id=5470 From noreply@sourceforge.net Thu Mar 6 19:15:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 11:15:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 6 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 14:15 Message: Logged In: YES user_id=12800 Looking at this again, note that the encoder has nothing to do with it. If you remove it you still get base64 encoded body, which /is/ reflected in the Content-Transfer-Encoding header. The base64 conversion is due to your use of the utf-8 character set for the body of the message. The utf-8 charset is defined as converting body text to base64. One approach to changing this may be to extend the SHORTEST notion to body encodings. I'm not inclined to change this, but if you want to discuss the matter, please bring it up on mimelib-devel@lists.python.org. ---------------------------------------------------------------------- Comment By: Kevin M. Turner (acapnotic) Date: 2002-10-26 06:11 Message: Logged In: YES user_id=9300 Ok, here's your smaller version. In Python 2.2.2, this makes a message with a base64 encoded body which is not automagically decoded by my email client. In Python 2.2.1, the body is cleartext. #!/usr/bin/env python2.2 from email.MIMEText import MIMEText from email import Encoders print MIMEText("e-mail message body", 'html', "utf-8", Encoders.encode_7or8bit) ---------------------------------------------------------------------- Comment By: Kevin M. Turner (acapnotic) Date: 2002-10-21 04:53 Message: Logged In: YES user_id=9300 I can't debug as much as I'd like, as I don't have parallel installations of 2.2.1 and 2.2.2, but I'll see if I can at least trim that down for you by throwing out all the non-email-package related bits. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:50 Message: Logged In: YES user_id=12800 I have not idea what the url has to do with it either, but I was hoping it would be a simple example of "this code [that] broke when [he] upgraded python from 2.2.1 to 2.2.2". It doesn't appear to be, or at least it doesn't appear to be a simple boiled down example, and I'm too tired right now to slog through all this code. Kevin, can you please upload a simple, reproducible script illustrating the breakage? I'll look at it tomorrow, unless Insomniac Timbot beats me to it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-21 01:31 Message: Logged In: YES user_id=31435 I don't know what the URL has to do with this, but since I'm running on a modern OS I was able to get it for you . See attachment. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:12 Message: Logged In: YES user_id=12800 Is that url meant to point to the example code that illustrates the problem? If so, could you please upload it to this bug report instead. I'm not able to grab the file with wget. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 19:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Thu Mar 6 19:21:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 11:21:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: Wont Fix Priority: 6 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 14:21 Message: Logged In: YES user_id=12800 Make that mimelib-devel@lists.sourceforge.net ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 14:15 Message: Logged In: YES user_id=12800 Looking at this again, note that the encoder has nothing to do with it. If you remove it you still get base64 encoded body, which /is/ reflected in the Content-Transfer-Encoding header. The base64 conversion is due to your use of the utf-8 character set for the body of the message. The utf-8 charset is defined as converting body text to base64. One approach to changing this may be to extend the SHORTEST notion to body encodings. I'm not inclined to change this, but if you want to discuss the matter, please bring it up on mimelib-devel@lists.python.org. ---------------------------------------------------------------------- Comment By: Kevin M. Turner (acapnotic) Date: 2002-10-26 06:11 Message: Logged In: YES user_id=9300 Ok, here's your smaller version. In Python 2.2.2, this makes a message with a base64 encoded body which is not automagically decoded by my email client. In Python 2.2.1, the body is cleartext. #!/usr/bin/env python2.2 from email.MIMEText import MIMEText from email import Encoders print MIMEText("e-mail message body", 'html', "utf-8", Encoders.encode_7or8bit) ---------------------------------------------------------------------- Comment By: Kevin M. Turner (acapnotic) Date: 2002-10-21 04:53 Message: Logged In: YES user_id=9300 I can't debug as much as I'd like, as I don't have parallel installations of 2.2.1 and 2.2.2, but I'll see if I can at least trim that down for you by throwing out all the non-email-package related bits. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:50 Message: Logged In: YES user_id=12800 I have not idea what the url has to do with it either, but I was hoping it would be a simple example of "this code [that] broke when [he] upgraded python from 2.2.1 to 2.2.2". It doesn't appear to be, or at least it doesn't appear to be a simple boiled down example, and I'm too tired right now to slog through all this code. Kevin, can you please upload a simple, reproducible script illustrating the breakage? I'll look at it tomorrow, unless Insomniac Timbot beats me to it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-21 01:31 Message: Logged In: YES user_id=31435 I don't know what the URL has to do with this, but since I'm running on a modern OS I was able to get it for you . See attachment. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:12 Message: Logged In: YES user_id=12800 Is that url meant to point to the example code that illustrates the problem? If so, could you please upload it to this bug report instead. I'm not able to grab the file with wget. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 19:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Thu Mar 6 22:16:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 14:16:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-697256 ] PyMarshal_WriteShortToFile() documented, but not implemented Message-ID: Bugs item #697256, was opened at 2003-03-04 08:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Neal Norwitz (nnorwitz) Summary: PyMarshal_WriteShortToFile() documented, but not implemented Initial Comment: $ grep -r PyMarshal_WriteShortToFile * Doc/api/utilities.tex:\begin{cfuncdesc}{void}{PyMarshal_WriteShortToFile}{short value, FILE *file} Include/marshal.h:PyAPI_FUNC(void) PyMarshal_WriteShortToFile(int, FILE *); I guess it is a historic function that was removed at some point? Appears in both Python 2.2.2 and 2.3a2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 17:16 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Include/marshal.h 2.13 * Doc/api/utilities.tex 1.8 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-06 08:10 Message: Logged In: YES user_id=6380 Go ahead! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:28 Message: Logged In: YES user_id=33168 Guido, any problem removing the doc and prototype? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697256&group_id=5470 From noreply@sourceforge.net Thu Mar 6 23:15:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 15:15:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-699068 ] Error using Tkinter embeded in C++ Message-ID: Bugs item #699068, was opened at 2003-03-06 23:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699068&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: John (johnnoone) Assigned to: Nobody/Anonymous (nobody) Summary: Error using Tkinter embeded in C++ Initial Comment: Using Python 2.2.2 on MS Windows 2000 platform. Calling embedded Python from Visual C++ works fine until I add a call to Tkinter (version 8.3). Follow the example in section 5.3 at the following link: http://www.python.org/doc/ext/extending-with- embedding.html Link call.cpp as is and add a line to multiply.py to create a Tkinter frame: "fr = Tkinter.Tk()" // added import for Tkinter too! Yields the following error messages: C:\Python22\c\vcpp\hello3>hello3 call multiply 2 3 Thy shall add 2 times 3 Traceback (most recent call last): File "C:\Python22\c\vcpp\hello3\call.py", line 7, in multiply fr = Tk() File "C:\Python22\lib\lib-tk\Tkinter.py", line 1491, in __init__ baseName = os.path.basename(sys.argv[0]) AttributeError: 'module' object has no attribute 'argv' Call failed Is there a problem using Tkinter from C++? Python/Tk work fine standalone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699068&group_id=5470 From noreply@sourceforge.net Thu Mar 6 23:49:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 15:49:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-699079 ] HTMLParser crash on glued tag attributes Message-ID: Bugs item #699079, was opened at 2003-03-07 00:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser crash on glued tag attributes Initial Comment: HTMLParser.HTMLParser and derived classes crash when two tag attributes are glued like: WIDTH="512"HEIGHT="83" Example from IDLE: >>> import HTMLParser >>> BUGTEXT = """
""" >>> parser = HTMLParser.HTMLParser() >>> parser.feed(BUGTEXT) >>> parser.close() Traceback (most recent call last): File "", line 1, in ? parser.close() File "C:\Python22\lib\HTMLParser.py", line 112, in close self.goahead(1) File "C:\Python22\lib\HTMLParser.py", line 166, in goahead self.error("EOF in middle of construct") File "C:\Python22\lib\HTMLParser.py", line 115, in error raise HTMLParseError(message, self.getpos()) HTMLParseError: EOF in middle of construct, at line 6, column 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470 From noreply@sourceforge.net Fri Mar 7 00:09:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 16:09:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-697556 ] test_posix fails: getlogin Message-ID: Bugs item #697556, was opened at 2003-03-04 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Neal Norwitz (nnorwitz) Summary: test_posix fails: getlogin Initial Comment: I see bug #690081 made this run only in interactive mode, but it still fails for me when I do a make test. Apparently my utmp is in an unexpected place, /var/run/, which I guess doesn't agree with my libc? I don't know how common this bug will be for other people, but if anyone else experiences it you should probably just get rid of the getlogin test altogether, or at least catch the OSError: (2, 'No such file or directory') and don't have that mean test failure. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 19:09 Message: Logged In: YES user_id=33168 Michael, can you test the attached patch? It should fix the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:26 Message: Logged In: YES user_id=33168 I'll take a look at this soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 From noreply@sourceforge.net Fri Mar 7 00:09:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 16:09:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-639806 ] Optional argument for dict.pop() method Message-ID: Bugs item #639806, was opened at 2002-11-17 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639806&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fernando Pérez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Optional argument for dict.pop() method Initial Comment: I think the new dict.pop() method should support an optional argument for its return value when a key is not found. The current behavior (raising KeyError always) IMHO violates the principle of least surprise, since the very similar get() method _does_ support an optional return value. I am filing this as a bug on suggestion by Neil Schemenauer in c.l.py. Here is a python proof of concept which I am using , implemented as a function. If this were accepted, similar behavior would need to be coded in the pop() method itself, which I suppose is part of the C core. #---------------------------------------------------------------------------- class NotGiven: pass def popkey(dct,key,default=NotGiven): """Return dct[key] and delete dct[key]. dct is modified in-place. If default is given, return it if dct[key] doesn't exist, otherwise raise KeyError. """ try: val = dct[key] except KeyError: if default is NotGiven: raise else: return default else: del dct[key] return val #---------------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-06 19:09 Message: Logged In: YES user_id=80475 Fixed when patch 693753 was applied. ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2003-02-26 14:10 Message: Logged In: YES user_id=395388 I've just been too busy to code the patch, but I'm glad to see that mbrierst stepped up to the plate. I do find the feature rather useful, but for a more thorough discussion, the original thread from c.l.py can be read. Here is A. Martelli's take on the issue, with his usual level of care and detail: http://groups.google.com/groups?q=dict.pop&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Bm2C9.29398%24Yw.1473263%40news2.tin.it&rnum=1 ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-26 11:54 Message: Logged In: YES user_id=670441 I'm not sure how "compelling" people will find it, but I submitted patch 693753 to implement this behavior. If it is not desired, this bug should probably be closed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 18:17 Message: Logged In: YES user_id=21627 No need to worry. If somebody gets it done before, they will just close this report, so you'll know its done. Otherwise, we can leave it open nearly indefinitely - we are all insanely busy, all the time :-) ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2002-11-18 14:35 Message: Logged In: YES user_id=395388 Martin, I'd love to give it a go, but right now I'm insanely busy (I shouldn't even be worrying about this :) In about two weeks things will calm down a bit though, and I could look into it. But I don't know the interpreter core at all, so I'd probably need a bit of guidance as to what files to look at (I don't want to spend an afternoon grepping). And I know very little about the python interenals (for example, about how to handle python exceptions from the C side). But with a bit of guidance I can manage. So if nobody else who knows the system well and can do it in 10 minutes is interested, and if someone is willing to point me in the right direction, I can look into it two/three weeks from now. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 07:17 Message: Logged In: YES user_id=21627 Fernando, I sympathize with this request in principle, although I'm concerned about the ever-growing complexity of dictionary methods. Would you be interested in implementing an actual patch to provide this feature? ---------------------------------------------------------------------- Comment By: Fernando Pérez (fer_perez) Date: 2002-11-18 04:47 Message: Logged In: YES user_id=395388 This is a repost of my reply in c.l.py, for reference here. Alex Martelli just posted a detailed reply to c.l.py, roughly along the lines of mine (with more specific arguments and code examples). Raymond Hettinger wrote: > Do you have use cases demonstrating the value of a default rather than an > exception? Sure. First, on principle: the exception option is still there, if no default is provided. What giving a default buys you is not having to trap the exception yourself. If you want a missing key to generate an exception, simply don't give a default and that's it. Since it doesn't change the existing semantics (the current form doesn't take any arguments, so there can't be any confusion), I think it's a good addition. But you asked for code. Here's an example from a wrapper which needs to filter out a keyword dictionary given to a function before passing it downstream. It needs to remove keywords which won't be understood by the downstream function, but it knows how to make a default decision if the keyword wasn't given: # Filter out other options the original plot doesn't know hardcopy = popkey(keyw,'hardcopy',psargs['filename'] is not None) titles = popkey(keyw,'titles',0) This uses my popkey() function, with the new method it would be simply # Filter out other options the original plot doesn't know hardcopy = keyw.pop('hardcopy',psargs['filename'] is not None) titles = keyw.pop('titles',0) if my suggestion were accepted. I can always live with my popkey() function instead, if the crippled version is left in the language :) What I won't do is use the crippled pop() and wrap things everywhere with explicit try/except blocks. In the end that only hurts readaility and creates bloat. This is part of the Gnuplot wrappers in IPython, if you want to see the full code (or I can give more context). IPython lives at http://www-hep.colorado.edu/~fperez/ipython > Also, discuss why similarity with dict.get() applies instead of symmetry > with list.pop() or dict.popitem(). - list.pop: I wasn't looking when that was written :) But I could argue similarly that an optional default argument would be a sensible, useful addition. No semantic break for existing code, and it saves people setting up try/except traps. - dict.popitem: this one I'm ok with not having a default value, since it is meant to traverse the dict in essentially random order. Adding a default value would be like having a dict_with_default kind of object, which is definitely different from a regular python dict. popitem() returns a k/v pair and is typically used for exhausting a dict destructively, so it makes a lot of sense to break at the end. But pop(key) is much more specific, so I think it is sensible to be able to control its behavior more closely. Just like dict.get(), which allows straight through the function interface one to control what happens to missing keys. Semantically pop(key) is almost like get(key), with the difference that it deletes the k/v entry from the dict. It seems only natural then that pop() would support the same default arg behavior that get() has. Cheers, f. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-18 03:02 Message: Logged In: YES user_id=80475 dict.pop(k) parallels list.remove(elem), dict.popitem(), and list.pop([i]) which all raise exceptions instead of returning a default. Do you have compelling use cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639806&group_id=5470 From noreply@sourceforge.net Fri Mar 7 04:05:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 20:05:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-697556 ] test_posix fails: getlogin Message-ID: Bugs item #697556, was opened at 2003-03-04 22:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Neal Norwitz (nnorwitz) Summary: test_posix fails: getlogin Initial Comment: I see bug #690081 made this run only in interactive mode, but it still fails for me when I do a make test. Apparently my utmp is in an unexpected place, /var/run/, which I guess doesn't agree with my libc? I don't know how common this bug will be for other people, but if anyone else experiences it you should probably just get rid of the getlogin test altogether, or at least catch the OSError: (2, 'No such file or directory') and don't have that mean test failure. ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2003-03-07 04:05 Message: Logged In: YES user_id=670441 Yeah, this patched fixed it just fine. As long as I've got you here, should test_socket require the network resource be enabled? It only works for me when I'm connected. When not connected testHostnameRes fails because getfqdn() returns my hostname, 'zazz', but gethostbyaddr(ip) returns the hostname 'localhost'. When I am connected getfqdn() also returns 'localhost' so there's no problem. It could be fixed for me by either requiring the network resource or changing line 234 of test_socket from: all_host_names = [hname] + aliases to: all_host_names = [hname, hostname] + aliases Or maybe my machine's setup is just messed up in which case I trust you won't worry about it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-07 00:09 Message: Logged In: YES user_id=33168 Michael, can you test the attached patch? It should fix the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 06:26 Message: Logged In: YES user_id=33168 I'll take a look at this soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 From noreply@sourceforge.net Fri Mar 7 07:26:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 06 Mar 2003 23:26:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-699237 ] Tutorial uses omitted slice indices before explaining them Message-ID: Bugs item #699237, was opened at 2003-03-07 20:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699237&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Thomas (mpthomas) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial uses omitted slice indices before explaining them Initial Comment: Version: Python 2.2.2, Windows 98 This is a slight problem in section 3.1.2 of the Python tutorial, `Strings' . In the paragraph which begins `Unlike a C string, Python strings cannot be changed ...', the example uses an omitted slice index, before omitted slice indices have been explained. This could easily be fixed by moving this paragraph to the end of the section on slicing, which would have the additional benefit of not slicing the slicing section. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699237&group_id=5470 From noreply@sourceforge.net Fri Mar 7 10:59:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 02:59:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-699312 ] builtin type inconsistency Message-ID: Bugs item #699312, was opened at 2003-03-07 11:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: builtin type inconsistency Initial Comment: many builtin types can be called without arguments, yielding the 'false' (zero/empty) instance of their type. However, others can't. why is int()==0 but calling bool() raises an exception rather than returning False? I consider this irregularity a tiny bug. Arguably slice() should also return the same result as slice(None), again for regularity, but this is admittedly iffier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470 From noreply@sourceforge.net Fri Mar 7 13:38:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 05:38:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-699379 ] ncurses/curses on solaris Message-ID: Bugs item #699379, was opened at 2003-03-07 13:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699379&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Iain Morrison (iainmorrison) Assigned to: Nobody/Anonymous (nobody) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699379&group_id=5470 From noreply@sourceforge.net Fri Mar 7 13:51:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 05:51:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-690341 ] tarfile fails on MacOS9 Message-ID: Bugs item #690341, was opened at 2003-02-20 23:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690341&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jack Jansen (jackjansen) >Assigned to: Nobody/Anonymous (nobody) >Summary: tarfile fails on MacOS9 Initial Comment: test_tarfile fails in MacPython-OS9. The problem seems to be pathname-related, and I'm not sure whether the problem is with the test or with the tarfile module itself. Various of the tests (test_seek, test_readlines) expect to find a file called, for example, "0-REGTYPE-TEXT", while the archive holds a file "/0-REGTYPE-TEXT". Apparently the tarfile module has some support for os.sep being different than "/", but not enough. An added problem (or maybe the only problem?) may be that on the mac there are no files at the "root", only directories (disks, actually). So while "/tmp" is representable as "tmp:" this doesn't really work for files as they would be interpreted as directories. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-07 14:51 Message: Logged In: YES user_id=45365 The problem turns out to be deeper: the way tarfile handles pathnames needs work (and probably a lot of it). There is an assumption all over the code that you can convert unix pathnames to native pathnames by simply substitution / with os.path.sep. This will not fly for the Mac: /unix/path/name -> unix:path:name and relative/unix/path -> :relative:unix:path. I've rigger tarfile.py to raise ImportError on the mac, changed the summary of this bug and left it open/unassigned with a lower priority. Maybe someone finds the time to fix it, some time. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-23 23:05 Message: Logged In: YES user_id=33168 Jack, I don't really know how to fix these. My guess is that doing something like os.path.normpath or abspath on the names would help. The code in test_seek and test_readlines does this: file(os.path.join(dirname(), filename), "r") Could that be changed to: file(os.path.normpath(os.path.join(dirname(), filename)), "r") Perhaps, there should be a utility function to get the normalized name? I can try to make the changes, but can't build or test on MacOS 9. If you can suggest some changes, I can make a patch for you to try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690341&group_id=5470 From noreply@sourceforge.net Fri Mar 7 14:02:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 06:02:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-699386 ] test_unicode_file fails on MacOS9 Message-ID: Bugs item #699386, was opened at 2003-03-07 15:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699386&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: test_unicode_file fails on MacOS9 Initial Comment: Since test_support.py rev. 1.49 test_unicode_file has started failing on MacOS9. It used to be skipped (there are no unicode filename semantics on this platform), but the 1.49 change always defines TESTFN_ENCODING. As sys.getfilesystemencoding() returns None on MacOS9 this makes test_unicode_file fail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699386&group_id=5470 From noreply@sourceforge.net Fri Mar 7 15:22:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 07:22:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-699079 ] HTMLParser crash on glued tag attributes Message-ID: Bugs item #699079, was opened at 2003-03-07 00:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None >Priority: 1 Submitted By: Artur de Sousa Rocha (adsr) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser crash on glued tag attributes Initial Comment: HTMLParser.HTMLParser and derived classes crash when two tag attributes are glued like: WIDTH="512"HEIGHT="83" Example from IDLE: >>> import HTMLParser >>> BUGTEXT = """
""" >>> parser = HTMLParser.HTMLParser() >>> parser.feed(BUGTEXT) >>> parser.close() Traceback (most recent call last): File "", line 1, in ? parser.close() File "C:\Python22\lib\HTMLParser.py", line 112, in close self.goahead(1) File "C:\Python22\lib\HTMLParser.py", line 166, in goahead self.error("EOF in middle of construct") File "C:\Python22\lib\HTMLParser.py", line 115, in error raise HTMLParseError(message, self.getpos()) HTMLParseError: EOF in middle of construct, at line 6, column 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699079&group_id=5470 From noreply@sourceforge.net Fri Mar 7 15:25:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 07:25:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-591586 ] Get rid of etype struct Message-ID: Bugs item #591586, was opened at 2002-08-06 11:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&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: Get rid of etype struct Initial Comment: The 'etype' struct in typeobject.c prevents people like David Abrahams and Christian Tismer from defining C-level metatypes that add slots to the end of the type structure. It should be possible for type_new() to place the additional structures after an offset determined by tp_basicsize of the metatype, rather than at a fixed offset. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 10:25 Message: Logged In: YES user_id=6380 Done, see SF patch 696193. ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-09-05 07:31 Message: Logged In: YES user_id=105700 Hi again, I fixed a minor bug/omission in my patch. Also, the etype struct is now gone. Instead, there is a PyHeaptypeObject definition in object.h which simply can be used in your own extended type definition like this: struct _mytype = { PyHeaptypeObject etype; int field1; PyObject *something; char and_so_on[20]; } But I'm quite convinced that this is not the end of the story. I would like to solve the issue about how to efficiently call object methods from C which might be overridden? I believe we could provide an extension to heap types that handles this automatically. I'm working on a prototype. ciao - chris ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-09-03 14:12 Message: Logged In: YES user_id=105700 Hi Guido, I think I have a solution for this one, see the attached diff. I did what you suggested: Make the adressing of the members dependant from the metatype. The etype struct has lost its members[1] field, to make it easier to extend the structure. Instead, the allocator always adds one to the size, to have the sentinel in place. I did not yet publish the etype stucture, since I didn't find a good name and place for it. Testing was also not very thorow. I just checked that types work from Python and that I can add __slots__ to them. Will re-port this stuff to my Py2.2 Stackless base and try it out as base type for my own C types. ciao - chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470 From noreply@sourceforge.net Fri Mar 7 17:20:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 09:20:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 12:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Gustavo Niemeyer (niemeyer) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-07 17:20 Message: Logged In: YES user_id=7887 No problems. If you don't mind, I'd just to have a confirmation: are you sure I should move the new fields to the end, and leave a conditional member in the middle? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-04 10:07 Message: Logged In: YES user_id=38388 Same comments as Guido, plus: * in the interpreter state struct you should add the new fields to the end, not in the middle * the finalization phase is moved to a later point in the process; this could cause problems when finalizing codecs -- I guess we'll just have to see whether we get bug reports related to this; perhaps it's better to ZAP the dicts before ZAPping builtins etc. ?! Great work, Gustavo. Please check the patch in with the above changes. Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 14:41 Message: Logged In: YES user_id=6380 I can't review this beyond "it doesn't break the tests for me"; I suggest to assign to MAL for review. One note: I got a compiler warning implicit declaration of function `_PyCodecRegistry_Init' to fix, add static int _PyCodecRegistry_Init(void); /* Forward */ somewhere to the top of codecs.c. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-01 08:07 Message: Logged In: YES user_id=7887 Here is a proposed solution. It has been tested with the standard regression tests, and in an environment with multiple interpreters. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-12 13:13 Message: Logged In: YES user_id=7887 As discussed in python-dev, I'll work on that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 12:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 10:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 12:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Fri Mar 7 17:36:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 09:36:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Gustavo Niemeyer (niemeyer) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-07 18:36 Message: Logged In: YES user_id=38388 Oh, I see what you mean. In that case, it's OK to add them just before the optional parts. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-07 18:20 Message: Logged In: YES user_id=7887 No problems. If you don't mind, I'd just to have a confirmation: are you sure I should move the new fields to the end, and leave a conditional member in the middle? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-04 11:07 Message: Logged In: YES user_id=38388 Same comments as Guido, plus: * in the interpreter state struct you should add the new fields to the end, not in the middle * the finalization phase is moved to a later point in the process; this could cause problems when finalizing codecs -- I guess we'll just have to see whether we get bug reports related to this; perhaps it's better to ZAP the dicts before ZAPping builtins etc. ?! Great work, Gustavo. Please check the patch in with the above changes. Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 15:41 Message: Logged In: YES user_id=6380 I can't review this beyond "it doesn't break the tests for me"; I suggest to assign to MAL for review. One note: I got a compiler warning implicit declaration of function `_PyCodecRegistry_Init' to fix, add static int _PyCodecRegistry_Init(void); /* Forward */ somewhere to the top of codecs.c. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-01 09:07 Message: Logged In: YES user_id=7887 Here is a proposed solution. It has been tested with the standard regression tests, and in an environment with multiple interpreters. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-12 14:13 Message: Logged In: YES user_id=7887 As discussed in python-dev, I'll work on that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 13:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 11:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Fri Mar 7 19:58:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 11:58:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-699594 ] refcount problem involding debugger Message-ID: Bugs item #699594, was opened at 2003-03-07 19:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: refcount problem involding debugger Initial Comment: Barry and I have both seen a debug version of Python fail when we exit an interpreter after using pdb. The failure in both cases is reported in line 400 of frameobject.c on the first iteration of the loop that frees the stack. The object being decrefed has already been freed. I don't know how to reliably provoke the problem, but I do have a core file. (gdb) where #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40033bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x080e4aac in Py_AtExit (func=0xbfffba80) at ../Python/pythonrun.c:1369 #4 0x0807d767 in _Py_NegativeRefcount ( fname=0x8125884 "../Objects/frameobject.c", lineno=400, op=0x4078e114) at ../Objects/object.c:104 #5 0x08105e26 in frame_dealloc (f=0x81c0d24) at ../Objects/frameobject.c:400 #6 0x08081723 in _Py_Dealloc (op=0x81c0d24) at ../Objects/object.c:1976 #7 0x080e7522 in tb_dealloc (tb=0x40788b74) at ../Python/traceback.c:41 #8 0x08081723 in _Py_Dealloc (op=0x40788b74) at ../Objects/object.c:1976 #9 0x080e74ca in tb_dealloc (tb=0x40788cb4) at ../Python/traceback.c:40 #10 0x08081723 in _Py_Dealloc (op=0x40788cb4) at ../Objects/object.c:1976 #11 0x080e74ca in tb_dealloc (tb=0x40788cf4) at ../Python/traceback.c:40 #12 0x08081723 in _Py_Dealloc (op=0x40788cf4) at ../Objects/object.c:1976 #13 0x0807a197 in PyDict_DelItem (op=0x4007f994, key=0x4081a5e8) at ../Objects/dictobject.c:571 #14 0x0807d4de in PyDict_DelItemString (v=0x4007f994, key=0x8119ab0 "exc_traceback") at ../Objects/dictobject.c:1973 #15 0x080e5382 in PySys_SetObject (name=0x8119ab0 "exc_traceback", v=0x0) at ../Python/sysmodule.c:65 #16 0x080bfa91 in reset_exc_info (tstate=0x4007c028) at ../Python/ceval.c:2750 #17 0x080be907 in eval_frame (f=0x81c058c) at ../Python/ceval.c:2367 #18 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015c9c8, globals=0x401f2d54, locals=0x0, args=0x40773898, argcount=2, kws=0x0, kwcount=0, defs=0x40162ef0, defcount=1, closure=0x0) at ../Python/ceval.c:2602 #19 0x08108877 in function_call (func=0x4016a444, arg=0x40773884, kw=0x0) at ../Objects/funcobject.c:501 #20 0x0805bf67 in PyObject_Call (func=0x4016a444, arg=0x40773884, kw=0x0) at ../Objects/abstract.c:1755 #21 0x08063fd6 in instancemethod_call (func=0x4016a444, arg=0x40773884, kw=0x0) at ../Objects/classobject.c:2411 #22 0x0805bf67 in PyObject_Call (func=0x40730074, arg=0x40769f4c, kw=0x0) at ../Objects/abstract.c:1755 #23 0x0809b4f9 in slot_tp_call (self=0x406d2d54, args=0x40769f4c, kwds=0x0) at ../Objects/typeobject.c:4357 #24 0x0805bf67 in PyObject_Call (func=0x406d2d54, arg=0x40769f4c, kw=0x0) at ../Objects/abstract.c:1755 #25 0x080c186d in do_call (func=0x406d2d54, pp_stack=0xbfffc344, na=1, nk=0) at ../Python/ceval.c:3565 #26 0x080c1115 in call_function (pp_stack=0xbfffc344, oparg=1) at ../Python/ceval.c:3381 #27 0x080bd63f in eval_frame (f=0x8178f64) at ../Python/ceval.c:2055 #28 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015f810, globals=0x401f2d54, locals=0x0, args=0x40773240, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2602 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470 From noreply@sourceforge.net Fri Mar 7 20:08:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 12:08:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-699600 ] MIMEText's c'tor adds unwanted trailing newline to text Message-ID: Bugs item #699600, was opened at 2003-03-07 20:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIMEText's c'tor adds unwanted trailing newline to text Initial Comment: I have a web form that includes a "file" type . This means that it expects the HTTP POST data to be of type multipart/form-data. I was using the 'email' package to build this Message essentially like this: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(content) message.attach() this results in a message body (headers removed) like the following: --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="logfile"; filename="D:\trentm\tmp\seuss.txt" one fish two fish three fish blue fish --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="name" pliers --===============25164547096797829==-- The problem is those extra newlines after "blue fish" and after "pliers". My uploaded file "D:\trentm\tmp\seuss.txt" does not have a newline at the end. The result is that the file is changed (albeit slightly) on an HTTP upload. If I use IE6 or Mozilla 1.3 to file out this web form the multipart/form-data messages they generate do NOT include those extra newlines. The newlines were added by this code in the MIMEText's constructor: if text[-1] <> '\n': text += '\n' which has been around for a long time: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/mimelib/mimelib/mimelib/Text.py.diff? r1=1.1&r2=1.2 No real reason was given for adding this code, and it seems hard to defend it because if I change the above to the following I do not get the extra newlines: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(None) part.set_payload(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(None) part.set_payload(content) message.attach() I suppose it is possible that there is a backward compatibility issue in changing this behaviour. You would be a better judge of that impact, Barry. Perhaps you could kill two birds with one stone and deprecate MIMEText in favor of a newly named one that drops the already deprecated _encoding argument as well. Cheers, Trent ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470 From noreply@sourceforge.net Fri Mar 7 20:57:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 12:57:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-699594 ] refcount problem involding debugger Message-ID: Bugs item #699594, was opened at 2003-03-07 14:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: refcount problem involding debugger Initial Comment: Barry and I have both seen a debug version of Python fail when we exit an interpreter after using pdb. The failure in both cases is reported in line 400 of frameobject.c on the first iteration of the loop that frees the stack. The object being decrefed has already been freed. I don't know how to reliably provoke the problem, but I do have a core file. (gdb) where #0 0x42029331 in kill () from /lib/i686/libc.so.6 #1 0x40033bdb in raise () from /lib/i686/libpthread.so.0 #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6 #3 0x080e4aac in Py_AtExit (func=0xbfffba80) at ../Python/pythonrun.c:1369 #4 0x0807d767 in _Py_NegativeRefcount ( fname=0x8125884 "../Objects/frameobject.c", lineno=400, op=0x4078e114) at ../Objects/object.c:104 #5 0x08105e26 in frame_dealloc (f=0x81c0d24) at ../Objects/frameobject.c:400 #6 0x08081723 in _Py_Dealloc (op=0x81c0d24) at ../Objects/object.c:1976 #7 0x080e7522 in tb_dealloc (tb=0x40788b74) at ../Python/traceback.c:41 #8 0x08081723 in _Py_Dealloc (op=0x40788b74) at ../Objects/object.c:1976 #9 0x080e74ca in tb_dealloc (tb=0x40788cb4) at ../Python/traceback.c:40 #10 0x08081723 in _Py_Dealloc (op=0x40788cb4) at ../Objects/object.c:1976 #11 0x080e74ca in tb_dealloc (tb=0x40788cf4) at ../Python/traceback.c:40 #12 0x08081723 in _Py_Dealloc (op=0x40788cf4) at ../Objects/object.c:1976 #13 0x0807a197 in PyDict_DelItem (op=0x4007f994, key=0x4081a5e8) at ../Objects/dictobject.c:571 #14 0x0807d4de in PyDict_DelItemString (v=0x4007f994, key=0x8119ab0 "exc_traceback") at ../Objects/dictobject.c:1973 #15 0x080e5382 in PySys_SetObject (name=0x8119ab0 "exc_traceback", v=0x0) at ../Python/sysmodule.c:65 #16 0x080bfa91 in reset_exc_info (tstate=0x4007c028) at ../Python/ceval.c:2750 #17 0x080be907 in eval_frame (f=0x81c058c) at ../Python/ceval.c:2367 #18 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015c9c8, globals=0x401f2d54, locals=0x0, args=0x40773898, argcount=2, kws=0x0, kwcount=0, defs=0x40162ef0, defcount=1, closure=0x0) at ../Python/ceval.c:2602 #19 0x08108877 in function_call (func=0x4016a444, arg=0x40773884, kw=0x0) at ../Objects/funcobject.c:501 #20 0x0805bf67 in PyObject_Call (func=0x4016a444, arg=0x40773884, kw=0x0) at ../Objects/abstract.c:1755 #21 0x08063fd6 in instancemethod_call (func=0x4016a444, arg=0x40773884, kw=0x0) at ../Objects/classobject.c:2411 #22 0x0805bf67 in PyObject_Call (func=0x40730074, arg=0x40769f4c, kw=0x0) at ../Objects/abstract.c:1755 #23 0x0809b4f9 in slot_tp_call (self=0x406d2d54, args=0x40769f4c, kwds=0x0) at ../Objects/typeobject.c:4357 #24 0x0805bf67 in PyObject_Call (func=0x406d2d54, arg=0x40769f4c, kw=0x0) at ../Objects/abstract.c:1755 #25 0x080c186d in do_call (func=0x406d2d54, pp_stack=0xbfffc344, na=1, nk=0) at ../Python/ceval.c:3565 #26 0x080c1115 in call_function (pp_stack=0xbfffc344, oparg=1) at ../Python/ceval.c:3381 #27 0x080bd63f in eval_frame (f=0x8178f64) at ../Python/ceval.c:2055 #28 0x080bf4d3 in PyEval_EvalCodeEx (co=0x4015f810, globals=0x401f2d54, locals=0x0, args=0x40773240, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2602 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 15:57 Message: Logged In: YES user_id=6380 This is going to be tricky unless we find a reliable way to reproduce it. :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699594&group_id=5470 From noreply@sourceforge.net Fri Mar 7 20:57:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 12:57:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 12:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 15:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 16:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 11:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 11:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-09 21:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 17:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 14:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 12:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 13:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 15:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 20:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 17:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 11:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 14:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 12:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 12:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Fri Mar 7 21:09:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 13:09:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-699630 ] Erroneous error message from IDLE Message-ID: Bugs item #699630, was opened at 2003-03-07 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous error message from IDLE Initial Comment: I'm a Python beginner (wrote C programs before I needed GUIs) running 2.2.2 on Windows 98SE from the standard download from www.python.org. I first put a frame ObRef 'f' into a .grid() line instead of into the Label() line above it. When I "fixed" it, I put the 'f' in the Label() but forgot to remove it from .grid(). IDLE's error message identified the erroneous line but reported that '-bd' was not allowed. If it had identified '-f' as the culprit that would have saved me a lot of scrambling. A screen-shot of the code and the error message are attached (MS Word .doc format). The offending line is the seventh line in the code screen-shot. Thanks. Sorry if this is a duplicate. I have searched the python.org FAQ and the Source Forge error list without recognizing this problem in any of their titles. Roy Keir rmkeir@earthlink.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 From noreply@sourceforge.net Fri Mar 7 21:16:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 13:16:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-699634 ] Erroneous message from IDLE's parser Message-ID: Bugs item #699634, was opened at 2003-03-07 14:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699634&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous message from IDLE's parser Initial Comment: I'm a Python beginner (wrote C programs before I needed GUIs) running 2.2.2 on Windows 98SE from the standard download from www.python.org. I first put a frame ObRef 'f' into a .grid() line instead of into the Label() line above it. When I "fixed" it, I put the 'f' in the Label() but forgot to remove it from .grid(). IDLE's error message identified the erroneous line but reported that '-bd' was not allowed. If it had identified '-f' as the culprit that would have saved me a lot of scrambling. A screen-shot of the code and the error message are attached (MS Word .doc format). The offending line is the seventh line in the code screen-shot. Thanks. Sorry if this is a duplicate. I have searched the python.org FAQ and the Source Forge error list without recognizing this problem in any of their titles. Roy Keir rmkeir@earthlink.net When I tried to send the .doc file, it showed "no data", and I assumed the earlier 'SUBMIT" had been cancelled..Not so. When I converted the .doc file to .htm, it said I had already submitted the item, so I assume the second version was refused. I have changed the title to confuse your system and get the message through, and I apologize for the inadvertent spamming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699634&group_id=5470 From noreply@sourceforge.net Fri Mar 7 21:49:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 13:49:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-699634 ] Erroneous message from IDLE's parser Message-ID: Bugs item #699634, was opened at 2003-03-07 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699634&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous message from IDLE's parser Initial Comment: I'm a Python beginner (wrote C programs before I needed GUIs) running 2.2.2 on Windows 98SE from the standard download from www.python.org. I first put a frame ObRef 'f' into a .grid() line instead of into the Label() line above it. When I "fixed" it, I put the 'f' in the Label() but forgot to remove it from .grid(). IDLE's error message identified the erroneous line but reported that '-bd' was not allowed. If it had identified '-f' as the culprit that would have saved me a lot of scrambling. A screen-shot of the code and the error message are attached (MS Word .doc format). The offending line is the seventh line in the code screen-shot. Thanks. Sorry if this is a duplicate. I have searched the python.org FAQ and the Source Forge error list without recognizing this problem in any of their titles. Roy Keir rmkeir@earthlink.net When I tried to send the .doc file, it showed "no data", and I assumed the earlier 'SUBMIT" had been cancelled..Not so. When I converted the .doc file to .htm, it said I had already submitted the item, so I assume the second version was refused. I have changed the title to confuse your system and get the message through, and I apologize for the inadvertent spamming. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-07 16:49 Message: Logged In: YES user_id=33168 Roy, the problem with uploading files is a bug in SourceForge. I am closing this report since it's a duplicate. You should be able to upload an attachment to the original bug report. Remember to click the button 'Check to Upload and Attach a File:' and add the file. If possible, can you use a format other than ms word? Any image format should be fine. Also, there is a newer version of idle (see http://idlefork.sf.net). This may fix the problem and has many improvements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699634&group_id=5470 From noreply@sourceforge.net Fri Mar 7 23:11:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 15:11:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-675420 ] email.Header() encoding does not work properly Message-ID: Bugs item #675420, was opened at 2003-01-27 08:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header() encoding does not work properly Initial Comment: CMFCollectorNG uses email.Header() to encode the Subject of notification emails. In some case we discovered that Evolution and Mutt displayed an empty subject. The Subject "[CMFCollectorNG] #31 (Comment): noch: ein test" is converted to Subject: =?iso-8859-1?q?=5BCMFCollectorNG=5D_=2331_=28Comment=29=3A_ein=3A_test?= The problem seems to occur if there is more than one colon inside the subject. Mailings with "[CMFCollectorNG] #31 (Comment): noch ein test" as subject are recognized by the mail readers and being displayed. Upgrading to the latest email packages from the Python HEAD did not solve the problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:26 Message: Logged In: YES user_id=12800 I don't understand. Where's the email package error? It seems like you're complaining about some MUA bugs. Can you upload (not paste) a Python code sample that illustrates the bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 From noreply@sourceforge.net Fri Mar 7 23:11:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 15:11:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary Message-ID: Bugs item #667931, was opened at 2003-01-14 13:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: BoundaryError: multipart message with no defined boundary Initial Comment: More problems with the email package raising exceptions when trying to parse non-compliant messages. Even when lax parsing is enabled, a BoundaryError is raised when trying to parse the attached spam message. I'd like to see some sort of workaround to handle these cases more gracefully when when lax parsing is enabled. This behavior seems like 'strict' parsing behavior to me. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:31 Message: Logged In: YES user_id=12800 I see what you're saying, Jason, but I don't know how Parser could do much better. You can always fall back to email.Header.HeaderParser when all else fails (well all else modulo severely broken headers). ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-02-20 14:33 Message: Logged In: YES user_id=85984 As Python 2.3a2 was just released, I'm worried that this one is going to fall through the cracks before 2.3-final is released which would be unfortunate because it would mean I'd have to continue bundling my own copy of email with my applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 From noreply@sourceforge.net Fri Mar 7 23:20:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 15:20:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-624254 ] email 2.4.3 pkg mail header error Message-ID: Bugs item #624254, was opened at 2002-10-16 15:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624254&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email 2.4.3 pkg mail header error Initial Comment: email 2.4.3 pkg bundled with python 2.2.2 deletes parts of mail header string. My python environment is; Python 2.2.2 (#1, Oct 15 2002, 14:20:16) [GCC 2.95.3 20010315 (release)] on sunos5 This is a test script which reads a mail and write it back; --- #!/usr/bin/env python import email import sys print email.message_from_file(sys.stdin) --- The input and output are supposed to be the same, except for unix header line and some formatting changes, but with several test cases they are different. I attached two test cases which show differences. 1. file mail1_errorpart_in and mail1_errorpart_out: Input file has 6 "Received:" headers. There are missing parts in the 4th and 5th 'Received:' headers. Others are fine. 2. file mail2_errorpart_in and mail2_errorpart_out: Input file has broken "Cc:" header. The script converts it without warning/error but the converted "Cc:" header deletes several addresses. I trimmed test mails just to show error headers. If you need the whole one for debugging, let me know at "inyeol.lee@ieee.org". Inyeol Lee ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-07 18:20 Message: Logged In: YES user_id=12800 Both examples now work in email 2.5 / Python 2.3 cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624254&group_id=5470 From noreply@sourceforge.net Sat Mar 8 06:21:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 07 Mar 2003 22:21:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-699816 ] Canvas Widget origin is off-screen Message-ID: Bugs item #699816, was opened at 2003-03-07 23:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas Widget origin is off-screen Initial Comment: I'm a Python newbie, so be patient. I noticed that create- didn't place the item where I expected. My help@Python.org guru Matt Cowles suggested that highlightthickness (hT hereinafter) might be the culprit. I wasn't using hT, but I was using borderwidth (bd to all), and I eventually found the problem. I believe that it is an error in Tkinter, but I'll be happy to be corrected. I wrote a program to display the canvases with the four combinations of hT and bd, and later I doubled up to see if 'relief' with bd==0 had any effect. I'll try to upload the code (oops. It invoves two modules. I may have to send two messages, one with each module). Here is what I think happens, and what I think should happen : DOES: SHOULD: Tkinter finds screen coordinates cx, cy of Canvas same (crucial step omitted) tx, ty = cx, cy Tkinter translates cx, cy = cx - bd, cy -bd tx, ty = tx- bd, ty - bd Tkinter draws the border (width is 2*bd wider than the Canvas) draws the border Tkinter translates cx, cy = cx - hT, cy - hT tx, ty = tx - hT, ty - hT Tkinter draws the highlight box (width is 2*hT wider than the border) draws the hightlight box Tkinter delivers cx, cy as the origin of the Canvas delivers cx, cy as the origin The attached program, if it arrives, demonstrates this effect. Any one doing serious graphics will need to adjust the x,y values of every Canvas item they draw. Putting a wrapper around each to .get() the values of hT and bd (and others I haven't discovered yet ?) is feasible but awful. Putting a function at the top of each event callback function to correct the event object x and y is even more awkward. To preserve backwards compatibility, I suggest that Tkinter Canvas items all be given an extra set of x and y values, with distinctive names. The user can put any old values in the current x,y positional spots and use xcorrected = NN, ycorrected=NN to override the stuff in the positional spots. To handle the variable number of x,y pairs in create_polygon(), create_line(), and perhaps other, Tkinter might require that the new values be given in a tuple of pairs or two tuples (x0,x1,x2) & (y0,y1,y2) The attached file is TkCoords03.py The next error will include algGrid03.py. Hope you can get them together. Roy Keir newbieroy rmkeir@earthlink.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699816&group_id=5470 From noreply@sourceforge.net Sat Mar 8 10:37:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Mar 2003 02:37:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-699386 ] test_unicode_file fails on MacOS9 Message-ID: Bugs item #699386, was opened at 2003-03-07 15:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699386&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: test_unicode_file fails on MacOS9 Initial Comment: Since test_support.py rev. 1.49 test_unicode_file has started failing on MacOS9. It used to be skipped (there are no unicode filename semantics on this platform), but the 1.49 change always defines TESTFN_ENCODING. As sys.getfilesystemencoding() returns None on MacOS9 this makes test_unicode_file fail. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-08 11:37 Message: Logged In: YES user_id=21627 I forgot to commit the patch to test_unicode_file. This should be fixed in 1.7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699386&group_id=5470 From noreply@sourceforge.net Sat Mar 8 12:29:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Mar 2003 04:29:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 05:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Sat Mar 8 19:39:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 08 Mar 2003 11:39:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-700055 ] site.py should ignore trailing CRs in .pth files Message-ID: Bugs item #700055, was opened at 2003-03-08 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700055&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dan Everhart (d_everhart) Assigned to: Nobody/Anonymous (nobody) Summary: site.py should ignore trailing CRs in .pth files Initial Comment: When site.addpackage(), running on a posix (e.g. cygwin or linux) system, reads lines from a .pth file that have '\r\n' line terminators, the carriage return character interferes with both the import operation and the directory appending operation. The situation can arise, for example, when .pth files reside on a network directory that is shared between Windows and Posix installations and accessed by python interpreters running in both environments. Suggested change: replace site.py line 146: dir = f.readline() with dir = f.readline().rstrip() This change also eliminates the need for removing the newline at lines 154-155 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700055&group_id=5470 From noreply@sourceforge.net Sun Mar 9 17:05:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 09:05:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 11:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Raymond Hettinger (rhettinger) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 15:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 16:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 10:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 10:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-09 20:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 16:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 13:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 11:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 12:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 14:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 19:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 16:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 16:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 16:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 10:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 13:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 11:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 19:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 11:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Sun Mar 9 17:07:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 09:07:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) >Assigned to: Raymond Hettinger (rhettinger) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Sun Mar 9 17:09:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 09:09:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-699630 ] Erroneous error message from IDLE Message-ID: Bugs item #699630, was opened at 2003-03-07 16:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous error message from IDLE Initial Comment: I'm a Python beginner (wrote C programs before I needed GUIs) running 2.2.2 on Windows 98SE from the standard download from www.python.org. I first put a frame ObRef 'f' into a .grid() line instead of into the Label() line above it. When I "fixed" it, I put the 'f' in the Label() but forgot to remove it from .grid(). IDLE's error message identified the erroneous line but reported that '-bd' was not allowed. If it had identified '-f' as the culprit that would have saved me a lot of scrambling. A screen-shot of the code and the error message are attached (MS Word .doc format). The offending line is the seventh line in the code screen-shot. Thanks. Sorry if this is a duplicate. I have searched the python.org FAQ and the Source Forge error list without recognizing this problem in any of their titles. Roy Keir rmkeir@earthlink.net ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-09 12:09 Message: Logged In: YES user_id=80475 Sometimes the SF file upload doesn't take. Please re-attach your screen shot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 From noreply@sourceforge.net Sun Mar 9 17:57:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 09:57:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-696777 ] How to make a class iterable using a member generator. Message-ID: Bugs item #696777, was opened at 2003-03-03 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: How to make a class iterable using a member generator. Initial Comment: This should probably go at the end of 2.2.5 (LibRef). [I was trying all possible variations of __iter__ returning self, with next() as a method...] """If you are designing a class that should be iterable, i.e. you want to be able to say "for x in myClass:...", and, you also want the convenience of using a member function that is a generator to provide the items, your class' __iter__() method should return "self.myGenerator (self)". The object returned from this call is an iterator- generator that implements both of the required __iter__() and next() methods. Example: class Range10: def __init__(self): self.scale = 5 def __iter__(self): return Range10.generateItems(self) def generateItems(self): for i in range(10): yield i * self.scale There are a couple of subtleties here. First, only "user- defined functions" are converted to methods when accessed through a class or instance, i.e.myObject.foo () will extract the foo function wrap it up as a method object, insert myObject in the argument list and call it (LibRef: 3.2/Callable types/User-defined methods). [thanks to Alex M. for clarifying this issue for me] This automatic conversion does not happen for any other type of objects defined inside class scope. In our case, generateItems() will be a generator-iterator, i.e. not a "user-defined function". Thus the conversion to an instance method does not happen, and it is left as a static method of the class. [this seems like it might be a bug to me...]. To get around this irregularity, make sure your __iter__() calls generateItems() as a static method, and explictly passes self. """ -- bjorn ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-03-09 12:57 Message: Logged In: YES user_id=593130 As others have posted (with examples) on both c.l.py and py-dev, it is both possible and simpler to write __init__ itself as a generator function, thereby returning a generator-iterator object with the requisite __init_() and next() methods.. Since this does not seem to be obvious to many people, I would agree that *this* should be mentioned in the docs. All the rest of the discussion about access and static methods is irrelevant for this purpose. >>> from __future__ import generators >>> class Range10: ... def __init__(self,scale): ... self.scale = scale ... def __iter__(self): ... scale = self.scale ... for i in range(10): yield i * scale ... >>> for i in Range10(4): ... print i ... 0 4 8 12 16 20 24 28 32 36 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696777&group_id=5470 From noreply@sourceforge.net Sun Mar 9 19:16:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 11:16:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-698561 ] list.index() bhvr change > python2.x Message-ID: Bugs item #698561, was opened at 2003-03-06 03:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Wittfoth (wittfoth) Assigned to: Nobody/Anonymous (nobody) Summary: list.index() bhvr change > python2.x Initial Comment: #!/usr/bin/python """ Between python1.x and python2.x there has been a major undocumented (?) change in the behaviour of list.index(). (At least I have been unable to locate the relevant PEP.) The following snippet illustrates this problem, though the error was encountered in a more complex real world situation, where a prototype system developed under python1.52 is being realised in python2.2.2. """ class Order : def __init__ (self, ordernum) : self.num = ordernum def __eq__ (self, other) : if (hasattr(other, 'num')) : return self.num == other.num else : return self is other if __name__ == '__main__' : a = Order(123) b = Order(234) c = Order(345) d = Order(123) orders = [a, b, c, d] for o in orders : print orders.index(o) """ Under python1.4 (Solaris 5.6) and python1.52 (Linux 2.4.x) the output is as would be expected : 0 1 2 3 Under python2.1.1, python2.2.2 and python2.3a2 (all Linux 2.4.x),the output is : 0 1 2 0 >From python2.x, list.index() apparently tests for equivalence rather than for identity. This is wrong, not the least because it breaks existing code (and more importantly, existing design). More fundamentally the problem is that it makes dangerous the use of the __eq__ hook, to redefine object equivalence, and contravenes the 'principle of least surprise.' As far as I know, testing for identity (is) cannot be overriden, whereas testing for equivalence (==) can. That being the case it is clearly safer to hang list.index() on the fixed nature of identity, rather than the redefinable nature of equivalence. """ ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-03-09 14:16 Message: Logged In: YES user_id=593130 The documented behavior of list.index(o) is, and I suspect always has been (at least the first part) "s.index(x) return smallest i such that s[i] == x" "Raises ValueError when x is not found in s." If the matching were on identity, [some-literal].index(some- literal) would raise ValueError instead of returning 0 if some-literal were not interned or recorded in some way so that both references were to the same object. Making .index() dependent on the (changing) details of object implementation and interning would make it both surprising, version-dependent, and pretty useless. Since .list() was added 12 years ago, there have been two changes recorded in the CVS log: 1) flag multiple args as an error and 2) switch from list_compare() to the newer list_richcompare() (2 years ago).. This latter perhaps fixed a previous bug. When you write a .__eq__(s,o) method returning True, you are saying that you *want* the interpreter to see s==0 as True! So either don't do that, or write an 'iddex' function that does what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 From noreply@sourceforge.net Sun Mar 9 20:31:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 12:31:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-698561 ] list.index() bhvr change > python2.x Message-ID: Bugs item #698561, was opened at 2003-03-06 03:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 Category: None >Group: Not a Bug Status: Open >Resolution: Invalid Priority: 5 Submitted By: Armin Wittfoth (wittfoth) >Assigned to: Tim Peters (tim_one) Summary: list.index() bhvr change > python2.x Initial Comment: #!/usr/bin/python """ Between python1.x and python2.x there has been a major undocumented (?) change in the behaviour of list.index(). (At least I have been unable to locate the relevant PEP.) The following snippet illustrates this problem, though the error was encountered in a more complex real world situation, where a prototype system developed under python1.52 is being realised in python2.2.2. """ class Order : def __init__ (self, ordernum) : self.num = ordernum def __eq__ (self, other) : if (hasattr(other, 'num')) : return self.num == other.num else : return self is other if __name__ == '__main__' : a = Order(123) b = Order(234) c = Order(345) d = Order(123) orders = [a, b, c, d] for o in orders : print orders.index(o) """ Under python1.4 (Solaris 5.6) and python1.52 (Linux 2.4.x) the output is as would be expected : 0 1 2 3 Under python2.1.1, python2.2.2 and python2.3a2 (all Linux 2.4.x),the output is : 0 1 2 0 >From python2.x, list.index() apparently tests for equivalence rather than for identity. This is wrong, not the least because it breaks existing code (and more importantly, existing design). More fundamentally the problem is that it makes dangerous the use of the __eq__ hook, to redefine object equivalence, and contravenes the 'principle of least surprise.' As far as I know, testing for identity (is) cannot be overriden, whereas testing for equivalence (==) can. That being the case it is clearly safer to hang list.index() on the fixed nature of identity, rather than the redefinable nature of equivalence. """ ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-09 15:31 Message: Logged In: YES user_id=31435 Closing as NotABug. The difference in behavior is due to that __eq__ wasn't recognized as a special method at all before rich comparisons were added, so the __eq__ method wasn't even invoked in 1.4. If you intend to use your program across versions of Python that old, then you need to restrict yourself to features that existed in Pythons that old. In this case, define a __cmp__ method instead of __eq__, and you'll see the same behavior under all Pythons (__cmp__ has always been supported; __eq__ is a newer feature). Note that .index() has never tested for identity, always for equality. In 1.4, your class doesn't define an equality method, and when that's true Python falls back to comparing objects by memory address. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-03-09 14:16 Message: Logged In: YES user_id=593130 The documented behavior of list.index(o) is, and I suspect always has been (at least the first part) "s.index(x) return smallest i such that s[i] == x" "Raises ValueError when x is not found in s." If the matching were on identity, [some-literal].index(some- literal) would raise ValueError instead of returning 0 if some-literal were not interned or recorded in some way so that both references were to the same object. Making .index() dependent on the (changing) details of object implementation and interning would make it both surprising, version-dependent, and pretty useless. Since .list() was added 12 years ago, there have been two changes recorded in the CVS log: 1) flag multiple args as an error and 2) switch from list_compare() to the newer list_richcompare() (2 years ago).. This latter perhaps fixed a previous bug. When you write a .__eq__(s,o) method returning True, you are saying that you *want* the interpreter to see s==0 as True! So either don't do that, or write an 'iddex' function that does what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 From noreply@sourceforge.net Sun Mar 9 20:34:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 12:34:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-698561 ] list.index() bhvr change > python2.x Message-ID: Bugs item #698561, was opened at 2003-03-06 03:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 Category: None >Group: None >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Armin Wittfoth (wittfoth) >Assigned to: Nobody/Anonymous (nobody) Summary: list.index() bhvr change > python2.x Initial Comment: #!/usr/bin/python """ Between python1.x and python2.x there has been a major undocumented (?) change in the behaviour of list.index(). (At least I have been unable to locate the relevant PEP.) The following snippet illustrates this problem, though the error was encountered in a more complex real world situation, where a prototype system developed under python1.52 is being realised in python2.2.2. """ class Order : def __init__ (self, ordernum) : self.num = ordernum def __eq__ (self, other) : if (hasattr(other, 'num')) : return self.num == other.num else : return self is other if __name__ == '__main__' : a = Order(123) b = Order(234) c = Order(345) d = Order(123) orders = [a, b, c, d] for o in orders : print orders.index(o) """ Under python1.4 (Solaris 5.6) and python1.52 (Linux 2.4.x) the output is as would be expected : 0 1 2 3 Under python2.1.1, python2.2.2 and python2.3a2 (all Linux 2.4.x),the output is : 0 1 2 0 >From python2.x, list.index() apparently tests for equivalence rather than for identity. This is wrong, not the least because it breaks existing code (and more importantly, existing design). More fundamentally the problem is that it makes dangerous the use of the __eq__ hook, to redefine object equivalence, and contravenes the 'principle of least surprise.' As far as I know, testing for identity (is) cannot be overriden, whereas testing for equivalence (==) can. That being the case it is clearly safer to hang list.index() on the fixed nature of identity, rather than the redefinable nature of equivalence. """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-09 15:31 Message: Logged In: YES user_id=31435 Closing as NotABug. The difference in behavior is due to that __eq__ wasn't recognized as a special method at all before rich comparisons were added, so the __eq__ method wasn't even invoked in 1.4. If you intend to use your program across versions of Python that old, then you need to restrict yourself to features that existed in Pythons that old. In this case, define a __cmp__ method instead of __eq__, and you'll see the same behavior under all Pythons (__cmp__ has always been supported; __eq__ is a newer feature). Note that .index() has never tested for identity, always for equality. In 1.4, your class doesn't define an equality method, and when that's true Python falls back to comparing objects by memory address. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-03-09 14:16 Message: Logged In: YES user_id=593130 The documented behavior of list.index(o) is, and I suspect always has been (at least the first part) "s.index(x) return smallest i such that s[i] == x" "Raises ValueError when x is not found in s." If the matching were on identity, [some-literal].index(some- literal) would raise ValueError instead of returning 0 if some-literal were not interned or recorded in some way so that both references were to the same object. Making .index() dependent on the (changing) details of object implementation and interning would make it both surprising, version-dependent, and pretty useless. Since .list() was added 12 years ago, there have been two changes recorded in the CVS log: 1) flag multiple args as an error and 2) switch from list_compare() to the newer list_richcompare() (2 years ago).. This latter perhaps fixed a previous bug. When you write a .__eq__(s,o) method returning True, you are saying that you *want* the interpreter to see s==0 as True! So either don't do that, or write an 'iddex' function that does what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698561&group_id=5470 From noreply@sourceforge.net Sun Mar 9 21:44:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 13:44:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-699630 ] Erroneous error message from IDLE Message-ID: Bugs item #699630, was opened at 2003-03-07 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous error message from IDLE Initial Comment: I'm a Python beginner (wrote C programs before I needed GUIs) running 2.2.2 on Windows 98SE from the standard download from www.python.org. I first put a frame ObRef 'f' into a .grid() line instead of into the Label() line above it. When I "fixed" it, I put the 'f' in the Label() but forgot to remove it from .grid(). IDLE's error message identified the erroneous line but reported that '-bd' was not allowed. If it had identified '-f' as the culprit that would have saved me a lot of scrambling. A screen-shot of the code and the error message are attached (MS Word .doc format). The offending line is the seventh line in the code screen-shot. Thanks. Sorry if this is a duplicate. I have searched the python.org FAQ and the Source Forge error list without recognizing this problem in any of their titles. Roy Keir rmkeir@earthlink.net ---------------------------------------------------------------------- Comment By: Roy Keir (newbieroy) Date: 2003-03-09 14:44 Message: Logged In: YES user_id=728836 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-09 10:09 Message: Logged In: YES user_id=80475 Sometimes the SF file upload doesn't take. Please re-attach your screen shot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 From noreply@sourceforge.net Mon Mar 10 05:17:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 21:17:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-700650 ] Canvas origin is off-canvas in create_(). Workaround Message-ID: Bugs item #700650, was opened at 2003-03-09 22:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas origin is off-canvas in create_(). Workaround Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700650&group_id=5470 From noreply@sourceforge.net Mon Mar 10 05:20:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 21:20:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-700651 ] Canvas origin is off-canvas in create_(). Workaround Message-ID: Bugs item #700651, was opened at 2003-03-09 22:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700651&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas origin is off-canvas in create_(). Workaround Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir ps I got the "no data in the file" message again. If you will send me another URL or give me a PO address, I'll send the file by that more reliable path fyi, I use Netscape 4.7 Does that correlate with upload failures ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700651&group_id=5470 From noreply@sourceforge.net Mon Mar 10 11:54:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 03:54:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris Message-ID: Bugs item #700780, was opened at 2003-03-10 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Iain Morrison (iainmorrison) Assigned to: Nobody/Anonymous (nobody) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 From noreply@sourceforge.net Mon Mar 10 12:40:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 04:40:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-700798 ] fixes and cleanups for descriptor info Message-ID: Bugs item #700798, was opened at 2003-03-10 07:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700798&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: fixes and cleanups for descriptor info Initial Comment: fixes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700798&group_id=5470 From noreply@sourceforge.net Mon Mar 10 12:43:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 04:43:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-700798 ] fixes and cleanups for descriptor info Message-ID: Bugs item #700798, was opened at 2003-03-10 07:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700798&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fixes and cleanups for descriptor info Initial Comment: fixes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700798&group_id=5470 From noreply@sourceforge.net Mon Mar 10 13:43:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 05:43:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-700827 ] Compiler Limits (indentation) Message-ID: Bugs item #700827, was opened at 2003-03-10 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Two Inches (twoinches) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler Limits (indentation) Initial Comment: The reference manual does not mention the indentation limits of compiler implementations. Suggestion: In section 2.1.7 Indentation add the following at the end of the section: Implementations may explicity limit the maximum indentation level. For CPython check tokenizer.h for build specifics (default value is set to 100). For Jython check org.python.parser.PythonGrammerTokenManager (default value is set to 20). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700827&group_id=5470 From noreply@sourceforge.net Mon Mar 10 13:54:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 05:54:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-700831 ] email crashes on broken attachements Message-ID: Bugs item #700831, was opened at 2003-03-10 14:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700831&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email crashes on broken attachements Initial Comment: email.Utils._bdecode() does not fail gracefully on broken attachements. The documentation suggests (somewhat) that it should, though: [if] "the header is missing, the payload is returned as-is" A use-case can be found at http://sourceforge.net/tracker/index.php?func=detail&aid=691039&group_id=103&atid=100103 and a patch for it at: https://sourceforge.net/tracker/index.php?func=detail&aid=691055&group_id=103&atid=300103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700831&group_id=5470 From noreply@sourceforge.net Mon Mar 10 15:39:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 07:39:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-595217 ] asynchat problems multi-threaded Message-ID: Bugs item #595217, was opened at 2002-08-14 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595217&group_id=5470 Category: Python Library >Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: A.M. Kuchling (akuchling) Summary: asynchat problems multi-threaded Initial Comment: asynchat.async_chat.push has two problems when used in an application where the pusher and the main loop are run by different threads. 1. A "push" does not wake up the main loop. This may result in long delays (the loop, by default, uses a timeout of 30 s). The work around is an explicit wakeup on the loop. I do not have a solution for Windows (more generally an OS where select does not work for pipes). When select does work for pipes, a simple "wakeup" can be implemented by writing to a pipe the main loop is waiting for. 2. The "self.initiate_send" can lead to two identical sends (which should be only one!) under the condition above. Workaround is to remove the call. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-10 10:39 Message: Logged In: YES user_id=11375 Added to PEP 42 and closed; this would be a fair bit of work, and it's not clear many people use asynchat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595217&group_id=5470 From noreply@sourceforge.net Mon Mar 10 16:22:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:22:42 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-681533 ] Additional string stuff. Message-ID: Feature Requests item #681533, was opened at 2003-02-06 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Additional string stuff. Initial Comment: In a lot of my programs that mess with strings, I end up somewhere making a variable "ascii" via (string.maketrans('', '')). It's just a 256-character string comprising the ascii character set. I use it, oftentimes, simply to be able to turn the 'translate' method on strings into a 'delete' method -- if I want to, say, remove all the spaces in aString, I'd do (aString.translate(ascii, string.whitespace)). Certainly an ascii variable in the string module couldn't hurt, would fit in with ascii_letters, etc. and would at least standarize the name of the full ascii set sure to be present in many Python programs. A little further out there, but I think just as useful, would be a delete method on strings. So "foo bar baz".delete(string.whitespace) would return "foobarbaz". It would be equivalent to "foo bar baz".translate(ascii, string.whitespace), or the wildly inefficient: def delete(s, deleteChars): l = [] for c in s: if c not in deleteChars: l.append(c) return ''.join(l) Anyway, that's all I can think of. Do with it what you will. Jeremy ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 18:22 Message: Logged In: YES user_id=36166 Just make the interface like the translate method of unicode objects: it accepts "a mapping of Unicode ordinals to Unicode ordinals, Unicode strings or None. Unmapped characters are left untouched. Characters mapped to None are deleted.". This would make the str/unicode translate methods consistent (currently there is no way to call the method that will work for both). I have no opinion on whether implementing 1-to-n translations (like Python2.3 supports for unicode objects) is worth the trouble for plain strings. Of course, the table_string[, deletechars] interface should still be supported for compatibility. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-06 05:03 Message: Logged In: YES user_id=99508 Ah, yes, you're right. I never knew ASCII was only 7 bits per character. Perhaps string.all_characters? I just definitely think it should be publically available so there can be some consistency between applications that need a string of all 256 8-bit characters. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 16:13 Message: Logged In: YES user_id=45365 Note that "ascii" is definitely a bad name, as it means different things to anyone. To Python it usually means "7-bit ASCII" (as in the unicode "ascii" codec). To you it apparently means "8-bit something-or-other". I have no opinion on whether this feature is a good idea, but if it is I would suggest a name with "any" or "all" in it, and possibly "8bit" too. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-04 20:25 Message: Logged In: YES user_id=99508 What's the status on this? I checked string.py, and there actually already is a value that's the 256 ASCII characters, but it's called _idmap. Might we consider changing the name of that to "ascii"? I'd be happy to make the patch. Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 08:47 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 07:19 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-07 04:15 Message: Logged In: YES user_id=31435 Just noting that you can pass None for sep if you want to explicitly ask for the default behavior. >>> " a b c".split(None, 1) ['a', 'b c'] >>> ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-06 11:19 Message: Logged In: YES user_id=99508 Let me also make one other suggestion: the split method on a string object has, by default, behavior that can't be replicated by passing an argument as a separator. That is, the default separated acts like re.split(r'\s+'), but it's impossible to pass any value into the method to achieve that same result. The problem arises when a user wants to use the maxsplit() parameter to the method. Because maxsplit is a positional parameter instead of a keyword parameter, the user *must* declare a separate to split on, and thus loses his ability to split on whitespace-in-general. If maxsplit was changed from being a positional parameter to being a keyword parameter, then a programmer wouldn't have to give up the default behavior of the split method in order to pass it a maxsplit. At present, negative maxsplit values don't differ in any way from split's default behavior (with no maxsplit parameter given). Thus, the keyword maxsplit could default to -1 with no breakage of code. I can't see any place where changing maxsplit to a keyword parameter would break any existing code Jeremy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 From noreply@sourceforge.net Mon Mar 10 16:25:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:25:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-700831 ] email crashes on broken attachements Message-ID: Bugs item #700831, was opened at 2003-03-10 08:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700831&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email crashes on broken attachements Initial Comment: email.Utils._bdecode() does not fail gracefully on broken attachements. The documentation suggests (somewhat) that it should, though: [if] "the header is missing, the payload is returned as-is" A use-case can be found at http://sourceforge.net/tracker/index.php?func=detail&aid=691039&group_id=103&atid=100103 and a patch for it at: https://sourceforge.net/tracker/index.php?func=detail&aid=691055&group_id=103&atid=300103 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-10 11:25 Message: Logged In: YES user_id=12800 Fixed in Message.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700831&group_id=5470 From noreply@sourceforge.net Mon Mar 10 16:36:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:36:52 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-481962 ] Make modules callable Message-ID: Feature Requests item #481962, was opened at 2001-11-15 06:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Justin Shaw (justinshaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make modules callable Initial Comment: Many modules are have the same name as the main class they contain. I.E. gnu = Gnuplot.Gnuplot() Why not make modules callable. That is if a module contains a function called "__init__()" then that fucntion gets called whenever the code x = module(args) is encountered. Just an idea. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 18:36 Message: Logged In: YES user_id=36166 It'd be better to do that on `__call__`. One would expect `__init__` to be called when the module object is initialized (which is not really needed because you can write it in a the top level). This only makes sense as a complete upgrade of modules to object capabilities, i.e. `__add__`, `__getitem__`, `__setattr__` should be implemented then too. I'm not sure that's a good idea. To be precise, the above ideas lose the distinction between the type and it's instances - these special functions should only be called for instances of the module but moduels don't have instances... An alternative proposal: implement just one magic function, `__new__`, that if present is called at the end of the import and the object returned by it is used instead of the module. This allows any objects (e.g. class instances with all their magic) to be exposed as modules. You can already do this by installing any object in sys.modules; this would provide a clean way to do it from inside the module. ---------------------------------------------------------------------- Comment By: Thomas Justin Shaw (justinshaw) Date: 2003-01-24 02:19 Message: Logged In: YES user_id=135558 The problem with: from Gnuplot import Gnuplot is that now you cannot do: d = Gnuplot.Data() Yes, I agree "__call__" is more explicit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-23 06:48 Message: Logged In: YES user_id=80475 I don't think this shortcut gives an advantage over: from Gnuplot import Gnuplot . . . x = Gnuplot(args) ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2002-06-27 10:51 Message: Logged In: YES user_id=50945 Wouldn't calling a function named "__call__" make more sense than "__init__"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470 From noreply@sourceforge.net Mon Mar 10 16:45:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:45:10 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Mon Mar 10 16:52:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:52:35 -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: 3 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 Mon Mar 10 16:53:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:53:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-626452 ] Support RFC 2111 in email package Message-ID: Bugs item #626452, was opened at 2002-10-21 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626452&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support RFC 2111 in email package Initial Comment: Decide whether to support RFC 2111 in the email package. http://www.faqs.org/rfcs/rfc2111.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626452&group_id=5470 From noreply@sourceforge.net Mon Mar 10 16:59:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 08:59:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-594893 ] printing email object deletes whitespace Message-ID: Bugs item #594893, was opened at 2002-08-14 00:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: printing email object deletes whitespace Initial Comment: I certain situations when printing email Message objects (I think), whitespace in headers disappears. The attached zip file demonstrates this problem. In email.orig, there is a line break followed by a TAB in the X-Vm-v5-Data header at the end of the first continuation line. In email.new, which was generated by printing an email.Message object, the line break and TAB are gone, but no SPACE was inserted in their place. This example is from a larger program which reads in a Unix mailbox like so: msgdict = {} i = 0 for msg in mailbox.PortableUnixMailbox(f, email.Parser.Parser().parse): subj = msg["subject"] item = msgdict.get(subj) or [] item.append((i, msg)) msgdict[subj] = item i += 1 runs through msgdict and deletes a bunch of messages matching various criteria, then prints out those which remain retaining the relative order they had in the original mailbox: msglist = [] for val in msgdict.values(): msglist.extend(val) msglist.sort() for i,msg in msglist: print msg email.orig was plucked from the input mailbox and email.new from the output mailbox. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-10 11:59 Message: Logged In: YES user_id=12800 Skip, I'm finally getting back to this. In the latest cvs of email pkg (which will be 2.5), Header.encode() has an optional splitchars argument. If you were to load the X- header data into a Header instance and print it with splitchars='', then you should suppress splitting. Can you look to see if the semantics and API are appropriate for you? I'm closing the bug because I suspect you've long worked around it. If you don't care any more, you can just leave it closed . ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:52 Message: Logged In: YES user_id=12800 > Will that also solve the problem of space getting deleted? I'm not sure, give it a try! :) If not, then I think we'll add maxheaderlen=-1 to mean do no wrapping or filling of header values (which *should* take care of the problem). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 16:45 Message: Logged In: YES user_id=44345 > Why treat just the X-* header specially? Because of all the possible headers they are the ones we know the least about format-wise. From my selfish perspective, they are the ones I am having the most trouble with... ;-) I'd be happy to experiment with the maxheaderlen argument. I wasn't aware it existed. Will that also solve the problem of space getting deleted? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:32 Message: Logged In: YES user_id=12800 Why treat just the X-* header specially? BTW, the reason headers are wrapped in the first place is that RFC 2822 specifies hard and soft limits to header lengths. I think the hard limit is 998 characters, but it is recommended that no header be longer than 78 characters without wrapping. OTOH, a header like the X-VM-... header is for internal use only, so it's probably never used outside of your own applications. Note that you can suppress all wrapping by setting the maxheaderlen argument in the Generator's constructor to some outrageously large value (try 2000). Maybe a negative value should indicate that no wrapping of any headers be done? (Maybe limited to just non-encoded headers?) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 16:24 Message: Logged In: YES user_id=44345 A slightly less wild idea - why not just suppress all folding/reformatting for X-* headers and instead always emit the raw header value that was in the original message? That should solve the problem in the short term and allow you to come up with a suitable API for the longer term. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 16:04 Message: Logged In: YES user_id=12800 It doesn't, it just suggests that when wrapping a line: [...] folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. So it's really up to the application in most cases to define what the higher-level syntactic breaks should be. Problem is, the email package currently has no way for applications to tell it what to do for particular headers, so email tries a couple of simplistic generalized splitting algorithms (semi's then whitespace). Wild thought: allow each header to be assigned a splitting tokenizer method which does the "higher-level syntactic breaks". Tricky bits are to provide a useable API (where? in the Generator or in Message?), and what to do about encoded headers vs. ascii headers. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-10 15:51 Message: Logged In: YES user_id=44345 Hmmm... How can RFC 2822 presume to know anything about the syntax of X-* headers? Perhaps they should just be left alone... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-10 13:29 Message: Logged In: YES user_id=12800 Skip, you've got two difficult examples here. RFC 2822 recommends splitting lines at "the highest syntactic level" possible, but that differs depending on the semantics of the header. By default, Header._split_ascii() splits first on semicolons (for multiple parameter headers) and then on whitespace. Your two examples exploit weaknesses in this algorithm. In the first case, X-VM... has the syntax of a lisp expression. A coarser way to look at the contents would be to try to keep "-delimited strings without line breaks. The email package doesn't know anything about either of these syntactic levels. In the second case, you actually have X-Face data which contains a semi-colon, so the split mentioned above does the wrong thing in this case. I'm not sure what the best answer is. We can't hardcode too much syntactic information into the Header class. Do we need some kind of registration/callback mechanism so that applications can create their own tokenization routines for providing non-breaking tokens to the ascii_split() method? Yeesh. I'm up for suggestions. I can add a hack so that at least the X-VM header doesn't *lose* information when printed, but it's just a hack, so I'm not sure what the best solution is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 10:45 Message: Logged In: YES user_id=44345 Hmmm... Sometimes seems to *add* whitespace as well. Here's an example using the X-Face: header: Before: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3;}dS[43`qefo('''9?B=2a0u*B4u+a)$"DYl S After: X-Face: $LeJ8}Gzj%b'dmF:@bMiTrpT|UL=3O!CG~3; }dS[43`qefo('''9?B=2a0u*B4u+a)$"DYlS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594893&group_id=5470 From noreply@sourceforge.net Mon Mar 10 17:05:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 09:05:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-586899 ] email package does not work with mailbox Message-ID: Bugs item #586899, was opened at 2002-07-26 05:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586899&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Tim Peters (tim_one) Summary: email package does not work with mailbox Initial Comment: The email.message_from_file function does not seem to work correctly when used as the "factory" argument to the mailbox.UnixMailbox function. The "From_" separator line gets included in the preceding mail message. For a demonstration of this, see the attached zip file. The Python code loads the first message in the mailbox file and then displays the final line. This shows the From_ line from the subsequent message (correctly quoted with a ">"!!!). This is with Python 2.2 on Windows 2000. The Python banner line is Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-10 12:05 Message: Logged In: YES user_id=12800 Since this makes no difference for *nix and I don't have a Windows box to play with, I'm assigning to Tim. He can thank me later. Paul's explanation seems reasonable, but without a patch, I doubt any of us have motivation to fix it. I'd be happy with a documentation change. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-26 11:59 Message: Logged In: YES user_id=12800 I don't have time to comment except to say that email.message_from_file() definitely works as the factory function for mailbox.UnixMailbox. As proof, I have the following code in Mailman: class Mailbox(mailbox.PortableUnixMailbox): def __init__(self, fp): mailbox.PortableUnixMailbox.__init__(self, fp, email.message_from_file) so I know it works. :) I'll look at the comments Paul's made when I get a chance. I'm assigning this bug report to me. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-07-26 10:06 Message: Logged In: YES user_id=113328 This is a text vs binary file issue with the mailbox module, not with email. The "fp" parameter to the [Portable]UnixMailbox class must be opened in binary mode, or incorrect results are obtained. This is caused by the implementation of _Subfile.read() in mailbox.py, which assumes that number of characters read is the same as the difference between tell() values, an assumption which fails for text mode files on Windows. I would consider this behaviour a bug, and would prefer it to be fixed. However, if it is not to be fixed, the documentation should be changed to note that the "fp" parameter for the mailbox constructor must be opened in binary mode. For MMDF and Babyl format mailboxes, it's arguably correct, as the file format is binary. For Unix mailboxes, the file is text format, so opening the file in text mode is not unreasonable. Question: is the universal newline support in Python 2.3 going to mess this up further? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586899&group_id=5470 From noreply@sourceforge.net Mon Mar 10 17:22:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 09:22:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-699600 ] MIMEText's c'tor adds unwanted trailing newline to text Message-ID: Bugs item #699600, was opened at 2003-03-07 15:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIMEText's c'tor adds unwanted trailing newline to text Initial Comment: I have a web form that includes a "file" type . This means that it expects the HTTP POST data to be of type multipart/form-data. I was using the 'email' package to build this Message essentially like this: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(content) message.attach() this results in a message body (headers removed) like the following: --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="logfile"; filename="D:\trentm\tmp\seuss.txt" one fish two fish three fish blue fish --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="name" pliers --===============25164547096797829==-- The problem is those extra newlines after "blue fish" and after "pliers". My uploaded file "D:\trentm\tmp\seuss.txt" does not have a newline at the end. The result is that the file is changed (albeit slightly) on an HTTP upload. If I use IE6 or Mozilla 1.3 to file out this web form the multipart/form-data messages they generate do NOT include those extra newlines. The newlines were added by this code in the MIMEText's constructor: if text[-1] <> '\n': text += '\n' which has been around for a long time: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/mimelib/mimelib/mimelib/Text.py.diff? r1=1.1&r2=1.2 No real reason was given for adding this code, and it seems hard to defend it because if I change the above to the following I do not get the extra newlines: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(None) part.set_payload(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(None) part.set_payload(content) message.attach() I suppose it is possible that there is a backward compatibility issue in changing this behaviour. You would be a better judge of that impact, Barry. Perhaps you could kill two birds with one stone and deprecate MIMEText in favor of a newly named one that drops the already deprecated _encoding argument as well. Cheers, Trent ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-10 12:22 Message: Logged In: YES user_id=12800 I believe this was added to make sure that when a MIMEText was a subpart, the missing newline wouldn't break the appending of the boundary text. But we've since fixed that breakage in another way, so I think the code in MIMEText is wrong. Eliminating it breaks a bunch of unit tests but they appear easily reparable. The b/w compat issues are tougher since there may indeed be code relying on this. I don't want to deprecate the whole MIMEText class. Maybe the least painful is to add an argument to decide whether to add the newline or not. I'll bring this up on mimelib-devel and see what the consensus is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470 From noreply@sourceforge.net Mon Mar 10 17:48:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 09:48:31 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-10 17:48 Message: Logged In: YES user_id=6656 What steps need to be taken to acheive this? Would you be interested in working up a patch? I do most of my terminal hacking below the level of curses these days... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Mon Mar 10 20:53:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 12:53:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-701116 ] Bypassing upload failures. Tkinter origin-offset problem. Message-ID: Bugs item #701116, was opened at 2003-03-10 13:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701116&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing upload failures. Tkinter origin-offset problem. Initial Comment: I can't find mention of this in any FAQ or in your project titles. Since I have received a number for another problem and not for this one, I assume that even this part of the message was bagged when the upload came back with "file had no data". If not, please forgive the inadvertent spamming. If the user asks for a canvas of a given size, then uses coordinates within the given limits, I believe the user will expect to see everything sent using create_() calls. This is not the case. There is a band up the left side and another across the top of the canvas of size 'borderwidth + highlightthickness' that appears to be part of the canvas but is instead a dead zone. Apparently what should have been the canvas origin has been moved to draw the border and the highlight zone, then not restored. As a Python beginner, I was baffled by this. Lundh's Intro has very cryptic remarks about those options, but even looking back with some understanding of the problem, I find them Hopelessly inadequate. The problem may be in Tk itself. A quick experiment in Tck/Tk or PERL/Tk should tell. For myself, I had to solve the problem without spending months or years, so I wrote three functions that allow me to proceed. Uploads didn't get these to you, and apparently killed the rest of the message. Not good advertising for Source Forge or for whoever coded the upload facility. The function calls are: def UsrToCnv(xyTuple, cnvsInstance): def CnvToUsr(xyTuple, cnvsInstance): def tupInTupOut(xyTuple, xOffset, yOffset): Typical usage in painting canvas items: c = Canvas(f, width = 100, height = 75, etc. sq = (0,0, 0,74, 99,74, 99,0) c.create_polygon(UsrToCnv(sq, c), outline = "blue", fill = "") and in the other direction: def callClick(event): CnvToUsr((event.x, event.y), event.widget) I'll be happy to submit the code for this or for a graphics program that exposes the problem. Just ask. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701116&group_id=5470 From noreply@sourceforge.net Mon Mar 10 20:55:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 12:55:34 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 22:55 Message: Logged In: YES user_id=36166 Good question :-). Here are the basic additions of the wide curses interface: * `chtype` (which must be an integral type) donesn't have enough place to hold a character OR-ed with the attributes, nor would that be useful enough since combining characters must be handled. Therefore two types are intoroduced: ** attr_t - an integral type used to hold an OR-ed set of attributes that begin with the prefix ``WA_``. These attributes are semantically a superset of the ``A_`` ones and can have different values (although in ncurses they are the same). ** cchar_t - a type representing one character cell: at most one spacing character, an implementation-defined number of combining characters, attributes and a color pair. * A whole lot of new functions are provided using these new types. The distinguishing naming style is the separation of words with underscope. ** Functions that work on single chars have counterparts (``_wch``) that recieve/return cchar_t (except for get_wch which is a bogus mutation). ** Functions that work on strings have counterparts (``_wstr``) that recieve/return (wchar_t *); many also are duplicated with a (cchar_t *) interface (``_wchstr``). ** All old functions having to do with characters are semantically just degenerate compatibility interfaces to the new ones. * Semantics are defined for adding combining characters: if only non-spacing characters are given, they are added to the existing complex character; if a spacing character is present, the whole cell is replaced. * Semantics are defined for double-width characters (what happens when you break them in various ways). The simplest thing is just to wrap all the extra functions, exposing two APIs in Python, with the later only availible when the platform supports it. This would be painful to work with and I'd rather avoid it. A better approach is just to overload the old names to work with unicode strings. For single-character methods (e.g. `addch`), it's harder. The (character ordinal | attributes) interface for should be deprecated and only work for ascii chars, in a backwards-compatible way. The interface where the character and attributes are given as separate arguments can be cleanly extended to accept unicode characters/ordinals. The behaivour w.r.t. combing and double-width characters should be defined. Complex chars should be repsented as multi-char unicode strings (therefore unicode ordinals are a limited representation). I don't think anything special is needed for sensible double-width handling? The (char_t *) interfaces (``_wchstr``) are convenient for storing many characters with inividual attributes; I'm not sure how to expose them (list of char, attr tuples?). There is the question of what to do in the absense of wide curses in the platform, when the unicode interface will be called. I think that some settable "curses default encoding" should be used as a fallback, so that people can keep their sanity. This should be specific to curses, or maybe even settable per-window, so that some basic input/output methods can implemented as a codec (this is suboptimal but I think could be useful as a quick solution). I can write an initial patch but don't expect it quickly. This could use the counsel of somebody with wide-curses expereince (I'm a newbe to this, I want to start experimenting in Python rather than C :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-10 19:48 Message: Logged In: YES user_id=6656 What steps need to be taken to acheive this? Would you be interested in working up a patch? I do most of my terminal hacking below the level of curses these days... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Mon Mar 10 20:58:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 12:58:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-699237 ] Tutorial uses omitted slice indices before explaining them Message-ID: Bugs item #699237, was opened at 2003-03-07 02:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699237&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Thomas (mpthomas) >Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial uses omitted slice indices before explaining them Initial Comment: Version: Python 2.2.2, Windows 98 This is a slight problem in section 3.1.2 of the Python tutorial, `Strings' . In the paragraph which begins `Unlike a C string, Python strings cannot be changed ...', the example uses an omitted slice index, before omitted slice indices have been explained. This could easily be fixed by moving this paragraph to the end of the section on slicing, which would have the additional benefit of not slicing the slicing section. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699237&group_id=5470 From noreply@sourceforge.net Mon Mar 10 21:15:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 13:15:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-701135 ] except: grammar is incorrect Message-ID: Bugs item #701135, was opened at 2003-03-10 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701135&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Ferris (mferris1) Assigned to: Nobody/Anonymous (nobody) Summary: except: grammar is incorrect Initial Comment: In the Python Language Reference manual, it shows the try- except grammar as: try_exc_stmt::= "try" ":" suite ("except" [expression ["," target]] ":" suite)+ This implies that this is a valid except stanza: except TypeError or VaueError or KeyError: This syntax does not produce any errors, but it doesn't work as one would expect either. It only "excepts" the first exception in the expression; i.e. TypeError in this example. I am assuming the grammar doc just needs to be updated and this is not the intented syntax for except. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701135&group_id=5470 From noreply@sourceforge.net Tue Mar 11 10:37:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 02:37:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-701135 ] except: grammar is incorrect Message-ID: Bugs item #701135, was opened at 2003-03-10 21:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701135&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mark Ferris (mferris1) >Assigned to: Michael Hudson (mwh) Summary: except: grammar is incorrect Initial Comment: In the Python Language Reference manual, it shows the try- except grammar as: try_exc_stmt::= "try" ":" suite ("except" [expression ["," target]] ":" suite)+ This implies that this is a valid except stanza: except TypeError or VaueError or KeyError: This syntax does not produce any errors, but it doesn't work as one would expect either. It only "excepts" the first exception in the expression; i.e. TypeError in this example. I am assuming the grammar doc just needs to be updated and this is not the intented syntax for except. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-11 10:37 Message: Logged In: YES user_id=6656 No, the grammar is correct. >>> TypeError or VaueError or KeyError It may not be what you expected, but it's what's allowed: />> def e(): |.. import random |.. return random.choice([KeyError, TypeError]) \__ />> def f(): |.. try: |.. {}[2] |.. except e(): |.. print "caught 1" |.. except: |.. print "caught 2" \__ ->> f() caught 1 ->> f() caught 1 ->> f() caught 2 ->> f() caught 2 ->> f() caught 1 ->> ... and so on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701135&group_id=5470 From noreply@sourceforge.net Tue Mar 11 13:38:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 05:38:47 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2003-03-11 15:38 Message: Logged In: YES user_id=36166 One more issue: constants. I think the ``A_`` attribute constants should not be duplicated as ``WA_``; rather the same ``A_`` values will be accepted in all cases and translated to the corresponding ``WA_`` values when passing them to wide curses functions. ``WA_`` attributes that have no ``A_`` counterpart in curses should get one, possibly a long int: A_{HORIZONTAL,LEFT,LOW,RIGHT,TOP,VERTICAL}. Wait, we already define them ;-). But they might be availiable on some platforms only as ``WA_`` and not ``A_``... The ``ACS_`` constants also have ``WACS_`` counterparts that are (cchar_t *). Probably the later should be exposed as unicode strings instead of the Other constants added in XSI curses are: * EOF/WEOF (actually declared in , ; returned by `.getch()` - should be either exposed in the module or converted to something sensible (None?). getkey() currently segfaults(!) on end of file, should return empty string for consistency with `file.read()`... * KEY_CODE_YES - return value of `get_wch()` to indicate the code is a key. Should not be exposed. Update to previous message: the ``_wchstr`` family need not be supported, at least as long as ``chstr`` family isn't (I didn't notice there is such a thing). In long run, it might be useful (but then a completely new high-level wrapper of windows as directly subscriptable/sliceable and 2D arrays would be even better... Let's leave it for now). ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 22:55 Message: Logged In: YES user_id=36166 Good question :-). Here are the basic additions of the wide curses interface: * `chtype` (which must be an integral type) donesn't have enough place to hold a character OR-ed with the attributes, nor would that be useful enough since combining characters must be handled. Therefore two types are intoroduced: ** attr_t - an integral type used to hold an OR-ed set of attributes that begin with the prefix ``WA_``. These attributes are semantically a superset of the ``A_`` ones and can have different values (although in ncurses they are the same). ** cchar_t - a type representing one character cell: at most one spacing character, an implementation-defined number of combining characters, attributes and a color pair. * A whole lot of new functions are provided using these new types. The distinguishing naming style is the separation of words with underscope. ** Functions that work on single chars have counterparts (``_wch``) that recieve/return cchar_t (except for get_wch which is a bogus mutation). ** Functions that work on strings have counterparts (``_wstr``) that recieve/return (wchar_t *); many also are duplicated with a (cchar_t *) interface (``_wchstr``). ** All old functions having to do with characters are semantically just degenerate compatibility interfaces to the new ones. * Semantics are defined for adding combining characters: if only non-spacing characters are given, they are added to the existing complex character; if a spacing character is present, the whole cell is replaced. * Semantics are defined for double-width characters (what happens when you break them in various ways). The simplest thing is just to wrap all the extra functions, exposing two APIs in Python, with the later only availible when the platform supports it. This would be painful to work with and I'd rather avoid it. A better approach is just to overload the old names to work with unicode strings. For single-character methods (e.g. `addch`), it's harder. The (character ordinal | attributes) interface for should be deprecated and only work for ascii chars, in a backwards-compatible way. The interface where the character and attributes are given as separate arguments can be cleanly extended to accept unicode characters/ordinals. The behaivour w.r.t. combing and double-width characters should be defined. Complex chars should be repsented as multi-char unicode strings (therefore unicode ordinals are a limited representation). I don't think anything special is needed for sensible double-width handling? The (char_t *) interfaces (``_wchstr``) are convenient for storing many characters with inividual attributes; I'm not sure how to expose them (list of char, attr tuples?). There is the question of what to do in the absense of wide curses in the platform, when the unicode interface will be called. I think that some settable "curses default encoding" should be used as a fallback, so that people can keep their sanity. This should be specific to curses, or maybe even settable per-window, so that some basic input/output methods can implemented as a codec (this is suboptimal but I think could be useful as a quick solution). I can write an initial patch but don't expect it quickly. This could use the counsel of somebody with wide-curses expereince (I'm a newbe to this, I want to start experimenting in Python rather than C :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-10 19:48 Message: Logged In: YES user_id=6656 What steps need to be taken to acheive this? Would you be interested in working up a patch? I do most of my terminal hacking below the level of curses these days... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Tue Mar 11 14:06:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 06:06:33 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-11 14:06 Message: Logged In: YES user_id=6656 It sounds like you've given this more thought already than I'm likely to for some time :-) This is unlikely to make 2.3, I'd have thought, so there's no hurry, really. I can answer any questions about details of implementation and review any code you produce, but I think you have a better handle on design issues. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-11 13:38 Message: Logged In: YES user_id=36166 One more issue: constants. I think the ``A_`` attribute constants should not be duplicated as ``WA_``; rather the same ``A_`` values will be accepted in all cases and translated to the corresponding ``WA_`` values when passing them to wide curses functions. ``WA_`` attributes that have no ``A_`` counterpart in curses should get one, possibly a long int: A_{HORIZONTAL,LEFT,LOW,RIGHT,TOP,VERTICAL}. Wait, we already define them ;-). But they might be availiable on some platforms only as ``WA_`` and not ``A_``... The ``ACS_`` constants also have ``WACS_`` counterparts that are (cchar_t *). Probably the later should be exposed as unicode strings instead of the Other constants added in XSI curses are: * EOF/WEOF (actually declared in , ; returned by `.getch()` - should be either exposed in the module or converted to something sensible (None?). getkey() currently segfaults(!) on end of file, should return empty string for consistency with `file.read()`... * KEY_CODE_YES - return value of `get_wch()` to indicate the code is a key. Should not be exposed. Update to previous message: the ``_wchstr`` family need not be supported, at least as long as ``chstr`` family isn't (I didn't notice there is such a thing). In long run, it might be useful (but then a completely new high-level wrapper of windows as directly subscriptable/sliceable and 2D arrays would be even better... Let's leave it for now). ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 20:55 Message: Logged In: YES user_id=36166 Good question :-). Here are the basic additions of the wide curses interface: * `chtype` (which must be an integral type) donesn't have enough place to hold a character OR-ed with the attributes, nor would that be useful enough since combining characters must be handled. Therefore two types are intoroduced: ** attr_t - an integral type used to hold an OR-ed set of attributes that begin with the prefix ``WA_``. These attributes are semantically a superset of the ``A_`` ones and can have different values (although in ncurses they are the same). ** cchar_t - a type representing one character cell: at most one spacing character, an implementation-defined number of combining characters, attributes and a color pair. * A whole lot of new functions are provided using these new types. The distinguishing naming style is the separation of words with underscope. ** Functions that work on single chars have counterparts (``_wch``) that recieve/return cchar_t (except for get_wch which is a bogus mutation). ** Functions that work on strings have counterparts (``_wstr``) that recieve/return (wchar_t *); many also are duplicated with a (cchar_t *) interface (``_wchstr``). ** All old functions having to do with characters are semantically just degenerate compatibility interfaces to the new ones. * Semantics are defined for adding combining characters: if only non-spacing characters are given, they are added to the existing complex character; if a spacing character is present, the whole cell is replaced. * Semantics are defined for double-width characters (what happens when you break them in various ways). The simplest thing is just to wrap all the extra functions, exposing two APIs in Python, with the later only availible when the platform supports it. This would be painful to work with and I'd rather avoid it. A better approach is just to overload the old names to work with unicode strings. For single-character methods (e.g. `addch`), it's harder. The (character ordinal | attributes) interface for should be deprecated and only work for ascii chars, in a backwards-compatible way. The interface where the character and attributes are given as separate arguments can be cleanly extended to accept unicode characters/ordinals. The behaivour w.r.t. combing and double-width characters should be defined. Complex chars should be repsented as multi-char unicode strings (therefore unicode ordinals are a limited representation). I don't think anything special is needed for sensible double-width handling? The (char_t *) interfaces (``_wchstr``) are convenient for storing many characters with inividual attributes; I'm not sure how to expose them (list of char, attr tuples?). There is the question of what to do in the absense of wide curses in the platform, when the unicode interface will be called. I think that some settable "curses default encoding" should be used as a fallback, so that people can keep their sanity. This should be specific to curses, or maybe even settable per-window, so that some basic input/output methods can implemented as a codec (this is suboptimal but I think could be useful as a quick solution). I can write an initial patch but don't expect it quickly. This could use the counsel of somebody with wide-curses expereince (I'm a newbe to this, I want to start experimenting in Python rather than C :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-10 17:48 Message: Logged In: YES user_id=6656 What steps need to be taken to acheive this? Would you be interested in working up a patch? I do most of my terminal hacking below the level of curses these days... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Tue Mar 11 14:49:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 06:49:32 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2003-03-11 16:49 Message: Logged In: YES user_id=36166 OK. I don't care much whether it gets official quickly, I do want something to play with :-) (of course I want it to become official when it's good enough). I've looked a bit at the code. The prospect of double-casing all functions to use the wide interface is not pleasant but I don't see a better alternative yet; I'd like to factor things out if I find a way... And yes, any code I produce wll certainly require review :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-11 16:06 Message: Logged In: YES user_id=6656 It sounds like you've given this more thought already than I'm likely to for some time :-) This is unlikely to make 2.3, I'd have thought, so there's no hurry, really. I can answer any questions about details of implementation and review any code you produce, but I think you have a better handle on design issues. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-11 15:38 Message: Logged In: YES user_id=36166 One more issue: constants. I think the ``A_`` attribute constants should not be duplicated as ``WA_``; rather the same ``A_`` values will be accepted in all cases and translated to the corresponding ``WA_`` values when passing them to wide curses functions. ``WA_`` attributes that have no ``A_`` counterpart in curses should get one, possibly a long int: A_{HORIZONTAL,LEFT,LOW,RIGHT,TOP,VERTICAL}. Wait, we already define them ;-). But they might be availiable on some platforms only as ``WA_`` and not ``A_``... The ``ACS_`` constants also have ``WACS_`` counterparts that are (cchar_t *). Probably the later should be exposed as unicode strings instead of the Other constants added in XSI curses are: * EOF/WEOF (actually declared in , ; returned by `.getch()` - should be either exposed in the module or converted to something sensible (None?). getkey() currently segfaults(!) on end of file, should return empty string for consistency with `file.read()`... * KEY_CODE_YES - return value of `get_wch()` to indicate the code is a key. Should not be exposed. Update to previous message: the ``_wchstr`` family need not be supported, at least as long as ``chstr`` family isn't (I didn't notice there is such a thing). In long run, it might be useful (but then a completely new high-level wrapper of windows as directly subscriptable/sliceable and 2D arrays would be even better... Let's leave it for now). ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 22:55 Message: Logged In: YES user_id=36166 Good question :-). Here are the basic additions of the wide curses interface: * `chtype` (which must be an integral type) donesn't have enough place to hold a character OR-ed with the attributes, nor would that be useful enough since combining characters must be handled. Therefore two types are intoroduced: ** attr_t - an integral type used to hold an OR-ed set of attributes that begin with the prefix ``WA_``. These attributes are semantically a superset of the ``A_`` ones and can have different values (although in ncurses they are the same). ** cchar_t - a type representing one character cell: at most one spacing character, an implementation-defined number of combining characters, attributes and a color pair. * A whole lot of new functions are provided using these new types. The distinguishing naming style is the separation of words with underscope. ** Functions that work on single chars have counterparts (``_wch``) that recieve/return cchar_t (except for get_wch which is a bogus mutation). ** Functions that work on strings have counterparts (``_wstr``) that recieve/return (wchar_t *); many also are duplicated with a (cchar_t *) interface (``_wchstr``). ** All old functions having to do with characters are semantically just degenerate compatibility interfaces to the new ones. * Semantics are defined for adding combining characters: if only non-spacing characters are given, they are added to the existing complex character; if a spacing character is present, the whole cell is replaced. * Semantics are defined for double-width characters (what happens when you break them in various ways). The simplest thing is just to wrap all the extra functions, exposing two APIs in Python, with the later only availible when the platform supports it. This would be painful to work with and I'd rather avoid it. A better approach is just to overload the old names to work with unicode strings. For single-character methods (e.g. `addch`), it's harder. The (character ordinal | attributes) interface for should be deprecated and only work for ascii chars, in a backwards-compatible way. The interface where the character and attributes are given as separate arguments can be cleanly extended to accept unicode characters/ordinals. The behaivour w.r.t. combing and double-width characters should be defined. Complex chars should be repsented as multi-char unicode strings (therefore unicode ordinals are a limited representation). I don't think anything special is needed for sensible double-width handling? The (char_t *) interfaces (``_wchstr``) are convenient for storing many characters with inividual attributes; I'm not sure how to expose them (list of char, attr tuples?). There is the question of what to do in the absense of wide curses in the platform, when the unicode interface will be called. I think that some settable "curses default encoding" should be used as a fallback, so that people can keep their sanity. This should be specific to curses, or maybe even settable per-window, so that some basic input/output methods can implemented as a codec (this is suboptimal but I think could be useful as a quick solution). I can write an initial patch but don't expect it quickly. This could use the counsel of somebody with wide-curses expereince (I'm a newbe to this, I want to start experimenting in Python rather than C :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-10 19:48 Message: Logged In: YES user_id=6656 What steps need to be taken to acheive this? Would you be interested in working up a patch? I do most of my terminal hacking below the level of curses these days... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Tue Mar 11 14:52:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 06:52:01 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-700921 ] Wide-character curses Message-ID: Feature Requests item #700921, was opened at 2003-03-10 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Nobody/Anonymous (nobody) Summary: Wide-character curses Initial Comment: There exists a standard for wide-character curses (http://www.opengroup.org/onlinepubs/7908799/cursesix.html) and at least ncurses implements it (almost completely; you need to enable this when configuring it). It is essensial for getting the maximum of modern UTF-8 terminals (e.g. xterm). It would make sense for python's curses module to support all the wide functions on systems where the wide curses interface is present, especially since Python already supports unicode. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-11 14:52 Message: Logged In: YES user_id=6656 Cool. You should be able to extend the current preprocessor hackery to relieve some of the drudgery, shouldn't you? ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-11 14:49 Message: Logged In: YES user_id=36166 OK. I don't care much whether it gets official quickly, I do want something to play with :-) (of course I want it to become official when it's good enough). I've looked a bit at the code. The prospect of double-casing all functions to use the wide interface is not pleasant but I don't see a better alternative yet; I'd like to factor things out if I find a way... And yes, any code I produce wll certainly require review :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-11 14:06 Message: Logged In: YES user_id=6656 It sounds like you've given this more thought already than I'm likely to for some time :-) This is unlikely to make 2.3, I'd have thought, so there's no hurry, really. I can answer any questions about details of implementation and review any code you produce, but I think you have a better handle on design issues. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-11 13:38 Message: Logged In: YES user_id=36166 One more issue: constants. I think the ``A_`` attribute constants should not be duplicated as ``WA_``; rather the same ``A_`` values will be accepted in all cases and translated to the corresponding ``WA_`` values when passing them to wide curses functions. ``WA_`` attributes that have no ``A_`` counterpart in curses should get one, possibly a long int: A_{HORIZONTAL,LEFT,LOW,RIGHT,TOP,VERTICAL}. Wait, we already define them ;-). But they might be availiable on some platforms only as ``WA_`` and not ``A_``... The ``ACS_`` constants also have ``WACS_`` counterparts that are (cchar_t *). Probably the later should be exposed as unicode strings instead of the Other constants added in XSI curses are: * EOF/WEOF (actually declared in , ; returned by `.getch()` - should be either exposed in the module or converted to something sensible (None?). getkey() currently segfaults(!) on end of file, should return empty string for consistency with `file.read()`... * KEY_CODE_YES - return value of `get_wch()` to indicate the code is a key. Should not be exposed. Update to previous message: the ``_wchstr`` family need not be supported, at least as long as ``chstr`` family isn't (I didn't notice there is such a thing). In long run, it might be useful (but then a completely new high-level wrapper of windows as directly subscriptable/sliceable and 2D arrays would be even better... Let's leave it for now). ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 20:55 Message: Logged In: YES user_id=36166 Good question :-). Here are the basic additions of the wide curses interface: * `chtype` (which must be an integral type) donesn't have enough place to hold a character OR-ed with the attributes, nor would that be useful enough since combining characters must be handled. Therefore two types are intoroduced: ** attr_t - an integral type used to hold an OR-ed set of attributes that begin with the prefix ``WA_``. These attributes are semantically a superset of the ``A_`` ones and can have different values (although in ncurses they are the same). ** cchar_t - a type representing one character cell: at most one spacing character, an implementation-defined number of combining characters, attributes and a color pair. * A whole lot of new functions are provided using these new types. The distinguishing naming style is the separation of words with underscope. ** Functions that work on single chars have counterparts (``_wch``) that recieve/return cchar_t (except for get_wch which is a bogus mutation). ** Functions that work on strings have counterparts (``_wstr``) that recieve/return (wchar_t *); many also are duplicated with a (cchar_t *) interface (``_wchstr``). ** All old functions having to do with characters are semantically just degenerate compatibility interfaces to the new ones. * Semantics are defined for adding combining characters: if only non-spacing characters are given, they are added to the existing complex character; if a spacing character is present, the whole cell is replaced. * Semantics are defined for double-width characters (what happens when you break them in various ways). The simplest thing is just to wrap all the extra functions, exposing two APIs in Python, with the later only availible when the platform supports it. This would be painful to work with and I'd rather avoid it. A better approach is just to overload the old names to work with unicode strings. For single-character methods (e.g. `addch`), it's harder. The (character ordinal | attributes) interface for should be deprecated and only work for ascii chars, in a backwards-compatible way. The interface where the character and attributes are given as separate arguments can be cleanly extended to accept unicode characters/ordinals. The behaivour w.r.t. combing and double-width characters should be defined. Complex chars should be repsented as multi-char unicode strings (therefore unicode ordinals are a limited representation). I don't think anything special is needed for sensible double-width handling? The (char_t *) interfaces (``_wchstr``) are convenient for storing many characters with inividual attributes; I'm not sure how to expose them (list of char, attr tuples?). There is the question of what to do in the absense of wide curses in the platform, when the unicode interface will be called. I think that some settable "curses default encoding" should be used as a fallback, so that people can keep their sanity. This should be specific to curses, or maybe even settable per-window, so that some basic input/output methods can implemented as a codec (this is suboptimal but I think could be useful as a quick solution). I can write an initial patch but don't expect it quickly. This could use the counsel of somebody with wide-curses expereince (I'm a newbe to this, I want to start experimenting in Python rather than C :-). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-10 17:48 Message: Logged In: YES user_id=6656 What steps need to be taken to acheive this? Would you be interested in working up a patch? I do most of my terminal hacking below the level of curses these days... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470 From noreply@sourceforge.net Tue Mar 11 19:13:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 11:13:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-701751 ] WINDOW in py_curses.h needs ncurses-devel Message-ID: Bugs item #701751, was opened at 2003-03-11 13:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701751&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) Assigned to: Nobody/Anonymous (nobody) Summary: WINDOW in py_curses.h needs ncurses-devel Initial Comment: When trying to build 2.2.2 (Mandrake 9.1 Linux), I got errors when trying to compile _cursesmodule.c. This is because py_curses uses WINDOW. Ultimately, I traced this to my configuration: I had a curses.h file (from somewhere), I had ncurses 5.2 installed (part of the standard Mandrake RPM-based installation), but I didn't have libncurses-devel installed. I installed that RPM and the modules compiled (and tested) correctly. The "configure" program didn't catch this problem. Python compiled and ran anyway, but I would expect that the requirement for an obscure "devel" package ought to be flagged, either in the README or in the configure script. I'd submit a fix, but I don't know what the behavior is *supposed* to be. What I see from the output of "configure" is that configure *still* didn't find the "ncurses.h" file, even though the compiler caught it later. Logs of this compile on request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701751&group_id=5470 From noreply@sourceforge.net Tue Mar 11 21:34:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 13:34:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-701823 ] configure option --enable-shared make problems Message-ID: Bugs item #701823, was opened at 2003-03-11 21:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701823&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Uwe Hoffmann (qual) Assigned to: Nobody/Anonymous (nobody) Summary: configure option --enable-shared make problems Initial Comment: on building python 2.3.a2 with the following lines ./configure --prefix=/tmp/python --enable-shared --with-cxx=g++ --with-signal-module --with-threads ; make ; make install; the installed python interpreter cann't be started because libpython2.3.so.1.0 is installed but not libpython2.3.so . the attached patch works in my environment. Linux ; glibc 2.2.5; gcc 3.2; binutils 2.13 at least solaris should suffer from the same problem. (the change for configure.in is not tested, the changes were directly made to configure) the same can be achieved if libpython$(VERSION)$(SO) (actually libpython2.3.so ) is installed and not $(INSTSONAME) ( actually libpython2.3.so.1.0) . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701823&group_id=5470 From noreply@sourceforge.net Tue Mar 11 21:46:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 13:46:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-701836 ] Thread and os.systme or popen# Message-ID: Bugs item #701836, was opened at 2003-03-11 22:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik Öhman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: Thread and os.systme or popen# Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply@sourceforge.net Tue Mar 11 21:55:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 13:55:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-701836 ] Thread running (os.system or popen#) Message-ID: Bugs item #701836, was opened at 2003-03-11 22:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik Öhman (johanfo) Assigned to: Nobody/Anonymous (nobody) >Summary: Thread running (os.system or popen#) Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply@sourceforge.net Tue Mar 11 21:53:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 13:53:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-701836 ] Thread and os.system or popen# Message-ID: Bugs item #701836, was opened at 2003-03-11 22:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik Öhman (johanfo) Assigned to: Nobody/Anonymous (nobody) >Summary: Thread and os.system or popen# Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply@sourceforge.net Tue Mar 11 22:00:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 14:00:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-696253 ] PyMac_GetFSRef should accept unicode Message-ID: Bugs item #696253, was opened at 2003-03-03 00:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696253&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetFSRef should accept unicode Initial Comment: PyMac_GetFSRef() should accept a unicode filename argument, especially since calls like os.dir() can return unicode strings. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-11 23:00 Message: Logged In: YES user_id=45365 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696253&group_id=5470 From noreply@sourceforge.net Tue Mar 11 22:39:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 14:39:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 17:39 Message: Logged In: YES user_id=80475 Corvus, did you have any luck finding the offending lines in PmW? Can this bug be posted on PmW's SF site and closed here or do you guys think something still needs to be fixed in Python? ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 16:57 Message: Logged In: YES user_id=454042 We don't see the problem in Python 2.1. In fact initially we fell back to 2.1 but I don't want to stay there. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 15:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 12 01:29:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 17:29:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Raymond Hettinger (rhettinger) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 20:29 Message: Logged In: YES user_id=80475 I don't think the first part of the sentence is accurate. MRO conflicts can arise for less straight-forward reasons. How about: "Cannot create class. Superclasses A, B have conflicting inheritance trees which leave the method resolution order (MRO) undefined." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Wed Mar 12 02:50:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 18:50:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 05:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Raymond Hettinger (rhettinger) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- >Comment By: Bjorn Pettersen (bpettersen) Date: 2003-03-11 19:50 Message: Logged In: YES user_id=556638 Even better. If I were to suggest anything, it would be to add "(lookup)" after "resolution" since that seems to be the more frequently used terminology -- not a big issue though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 18:29 Message: Logged In: YES user_id=80475 I don't think the first part of the sentence is accurate. MRO conflicts can arise for less straight-forward reasons. How about: "Cannot create class. Superclasses A, B have conflicting inheritance trees which leave the method resolution order (MRO) undefined." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Wed Mar 12 02:54:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 18:54:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-701936 ] getsockopt/setsockopt with SO_RCVTIMEO are inconsistent Message-ID: Bugs item #701936, was opened at 2003-03-12 02:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701936&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: getsockopt/setsockopt with SO_RCVTIMEO are inconsistent Initial Comment: The SO_RCVTIMEO option to getsockopt/setsockopt seems to vary it's parameter format when used under Linux. With setsockopt, the parameter seems to be a struct of {long seconds, long microseconds}, as you would expect since it's modelling a C "struct timeval". However, with getsockopt, the parameter format seems to be {long seconds, long milliseconds} --- ie. it uses milliseconds rather than microseconds. The attached python script demonstrates this problem. Am I doing something crucially wrong, or is this meant to happen, or ... ? What I'm using: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701936&group_id=5470 From noreply@sourceforge.net Wed Mar 12 04:38:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 20:38:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Raymond Hettinger (rhettinger) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 23:38 Message: Logged In: YES user_id=80475 Fixed. See: Objects/typeobject.c 2.216 Lib/test/test_descr.py 1.187 ---------------------------------------------------------------------- Comment By: Bjorn Pettersen (bpettersen) Date: 2003-03-11 21:50 Message: Logged In: YES user_id=556638 Even better. If I were to suggest anything, it would be to add "(lookup)" after "resolution" since that seems to be the more frequently used terminology -- not a big issue though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 20:29 Message: Logged In: YES user_id=80475 I don't think the first part of the sentence is accurate. MRO conflicts can arise for less straight-forward reasons. How about: "Cannot create class. Superclasses A, B have conflicting inheritance trees which leave the method resolution order (MRO) undefined." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Wed Mar 12 05:04:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 11 Mar 2003 21:04:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-699237 ] Tutorial uses omitted slice indices before explaining them Message-ID: Bugs item #699237, was opened at 2003-03-07 02:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699237&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Thomas (mpthomas) Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial uses omitted slice indices before explaining them Initial Comment: Version: Python 2.2.2, Windows 98 This is a slight problem in section 3.1.2 of the Python tutorial, `Strings' . In the paragraph which begins `Unlike a C string, Python strings cannot be changed ...', the example uses an omitted slice index, before omitted slice indices have been explained. This could easily be fixed by moving this paragraph to the end of the section on slicing, which would have the additional benefit of not slicing the slicing section. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-12 00:04 Message: Logged In: YES user_id=80475 See tut.tex 1.178 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699237&group_id=5470 From noreply@sourceforge.net Wed Mar 12 08:59:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 00:59:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-701116 ] Bypassing upload failures. Tkinter origin-offset problem. Message-ID: Bugs item #701116, was opened at 2003-03-10 21:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701116&group_id=5470 Category: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing upload failures. Tkinter origin-offset problem. Initial Comment: I can't find mention of this in any FAQ or in your project titles. Since I have received a number for another problem and not for this one, I assume that even this part of the message was bagged when the upload came back with "file had no data". If not, please forgive the inadvertent spamming. If the user asks for a canvas of a given size, then uses coordinates within the given limits, I believe the user will expect to see everything sent using create_() calls. This is not the case. There is a band up the left side and another across the top of the canvas of size 'borderwidth + highlightthickness' that appears to be part of the canvas but is instead a dead zone. Apparently what should have been the canvas origin has been moved to draw the border and the highlight zone, then not restored. As a Python beginner, I was baffled by this. Lundh's Intro has very cryptic remarks about those options, but even looking back with some understanding of the problem, I find them Hopelessly inadequate. The problem may be in Tk itself. A quick experiment in Tck/Tk or PERL/Tk should tell. For myself, I had to solve the problem without spending months or years, so I wrote three functions that allow me to proceed. Uploads didn't get these to you, and apparently killed the rest of the message. Not good advertising for Source Forge or for whoever coded the upload facility. The function calls are: def UsrToCnv(xyTuple, cnvsInstance): def CnvToUsr(xyTuple, cnvsInstance): def tupInTupOut(xyTuple, xOffset, yOffset): Typical usage in painting canvas items: c = Canvas(f, width = 100, height = 75, etc. sq = (0,0, 0,74, 99,74, 99,0) c.create_polygon(UsrToCnv(sq, c), outline = "blue", fill = "") and in the other direction: def callClick(event): CnvToUsr((event.x, event.y), event.widget) I'll be happy to submit the code for this or for a graphics program that exposes the problem. Just ask. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-03-12 09:59 Message: Logged In: YES user_id=38376 I've added this feature request to PEP 42. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-03-12 09:59 Message: Logged In: YES user_id=38376 This is standard behaviour in Tk: "the origin of the canvas coordinate system is at the upper-left corner of the window containing the canvas". If you're not using scrollbars, you can use the xview/yview methods to realign the coordinate system: canvas = Canvas(...) canvas.xview_moveto(0) canvas.yview_moveto(0) If you're using scrollbars, the scrolling system will call xview/yview for youyou don't have to do anything. In either case, you must use the canvasx and canvasy methods to map from pixel coordinates to canvas coordinates. (btw, if you need to add a fixed offset to one or more items, it's usually faster to create the item and use the "move" method to apply the offset, instead of doing all calculations on the Python level). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701116&group_id=5470 From noreply@sourceforge.net Wed Mar 12 09:01:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 01:01:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-701116 ] Bypassing upload failures. Tkinter origin-offset problem. Message-ID: Bugs item #701116, was opened at 2003-03-10 21:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701116&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing upload failures. Tkinter origin-offset problem. Initial Comment: I can't find mention of this in any FAQ or in your project titles. Since I have received a number for another problem and not for this one, I assume that even this part of the message was bagged when the upload came back with "file had no data". If not, please forgive the inadvertent spamming. If the user asks for a canvas of a given size, then uses coordinates within the given limits, I believe the user will expect to see everything sent using create_() calls. This is not the case. There is a band up the left side and another across the top of the canvas of size 'borderwidth + highlightthickness' that appears to be part of the canvas but is instead a dead zone. Apparently what should have been the canvas origin has been moved to draw the border and the highlight zone, then not restored. As a Python beginner, I was baffled by this. Lundh's Intro has very cryptic remarks about those options, but even looking back with some understanding of the problem, I find them Hopelessly inadequate. The problem may be in Tk itself. A quick experiment in Tck/Tk or PERL/Tk should tell. For myself, I had to solve the problem without spending months or years, so I wrote three functions that allow me to proceed. Uploads didn't get these to you, and apparently killed the rest of the message. Not good advertising for Source Forge or for whoever coded the upload facility. The function calls are: def UsrToCnv(xyTuple, cnvsInstance): def CnvToUsr(xyTuple, cnvsInstance): def tupInTupOut(xyTuple, xOffset, yOffset): Typical usage in painting canvas items: c = Canvas(f, width = 100, height = 75, etc. sq = (0,0, 0,74, 99,74, 99,0) c.create_polygon(UsrToCnv(sq, c), outline = "blue", fill = "") and in the other direction: def callClick(event): CnvToUsr((event.x, event.y), event.widget) I'll be happy to submit the code for this or for a graphics program that exposes the problem. Just ask. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-03-12 10:01 Message: Logged In: YES user_id=38376 Ignore the PEP42 comment. *I* didn't write that myself; looks like SF decided to add a canned response all by it- self... ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-03-12 09:59 Message: Logged In: YES user_id=38376 I've added this feature request to PEP 42. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-03-12 09:59 Message: Logged In: YES user_id=38376 This is standard behaviour in Tk: "the origin of the canvas coordinate system is at the upper-left corner of the window containing the canvas". If you're not using scrollbars, you can use the xview/yview methods to realign the coordinate system: canvas = Canvas(...) canvas.xview_moveto(0) canvas.yview_moveto(0) If you're using scrollbars, the scrolling system will call xview/yview for youyou don't have to do anything. In either case, you must use the canvasx and canvasy methods to map from pixel coordinates to canvas coordinates. (btw, if you need to add a fixed offset to one or more items, it's usually faster to create the item and use the "move" method to apply the offset, instead of doing all calculations on the Python level). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701116&group_id=5470 From noreply@sourceforge.net Wed Mar 12 12:05:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 04:05:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Wed Mar 12 12:23:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 04:23:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python libraries. Message-ID: Bugs item #702157, was opened at 2003-03-12 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation of static/dynamic python libraries. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Wed Mar 12 12:40:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 04:40:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-701836 ] Thread running (os.system or popen#) Message-ID: Bugs item #701836, was opened at 2003-03-11 21:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik Öhman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: Thread running (os.system or popen#) Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p ) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-12 12:40 Message: Logged In: YES user_id=6656 IIRC, threads other than the main thread get a signal mask that blocks everything. That could be the problem, but I don't know what to do about it... What platform are you on? Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply@sourceforge.net Wed Mar 12 13:01:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 05:01:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 12:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Raymond Hettinger (rhettinger) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-12 13:01 Message: Logged In: YES user_id=6656 Unfortunately the new error message makes no sense when you get it by rearranging __bases__. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-12 04:38 Message: Logged In: YES user_id=80475 Fixed. See: Objects/typeobject.c 2.216 Lib/test/test_descr.py 1.187 ---------------------------------------------------------------------- Comment By: Bjorn Pettersen (bpettersen) Date: 2003-03-12 02:50 Message: Logged In: YES user_id=556638 Even better. If I were to suggest anything, it would be to add "(lookup)" after "resolution" since that seems to be the more frequently used terminology -- not a big issue though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-12 01:29 Message: Logged In: YES user_id=80475 I don't think the first part of the sentence is accurate. MRO conflicts can arise for less straight-forward reasons. How about: "Cannot create class. Superclasses A, B have conflicting inheritance trees which leave the method resolution order (MRO) undefined." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Wed Mar 12 13:12:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 05:12:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-702180 ] PackageManager can silently ignore errors Message-ID: Bugs item #702180, was opened at 2003-03-12 14:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702180&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager can silently ignore errors Initial Comment: If verbose is off and a build fails then PackageManager silently ignores the error, in stead of giving at least some feedback to the user. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702180&group_id=5470 From noreply@sourceforge.net Wed Mar 12 14:00:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 06:00:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-548109 ] Build fails in _curses module Message-ID: Bugs item #548109, was opened at 2002-04-24 14: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.2 Status: Open Resolution: None >Priority: 9 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: Ralf Hildebrandt (hildeb) Date: 2003-03-12 14:00 Message: Logged In: YES user_id=77128 Today I rebuild 2.2.2 and had exactly the same problem. My fix -- I commented out the explicit "extern int setupterm" declaration: /* These prototypes are in , but including this header #defines many common symbols (such as "lines") which breaks the curses module in other ways. So the code will just specify explicit prototypes here. */ //extern int setupterm(char *,int,int *); Comments: I have ncurses installed. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 14: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 14: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 Mar 12 14:15:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 06:15:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-548109 ] Build fails in _curses module Message-ID: Bugs item #548109, was opened at 2002-04-24 15: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.2 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: Michael Hudson (mwh) Date: 2003-03-12 14:15 Message: Logged In: YES user_id=6656 1) please don't dick with the priority... curses not building is never going to be priority 9, sorry 2) what version of ncurses do you have installed? 3) could you attach config.log/pyconfig.h? ---------------------------------------------------------------------- Comment By: Ralf Hildebrandt (hildeb) Date: 2003-03-12 14:00 Message: Logged In: YES user_id=77128 Today I rebuild 2.2.2 and had exactly the same problem. My fix -- I commented out the explicit "extern int setupterm" declaration: /* These prototypes are in , but including this header #defines many common symbols (such as "lines") which breaks the curses module in other ways. So the code will just specify explicit prototypes here. */ //extern int setupterm(char *,int,int *); Comments: I have ncurses installed. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 14: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 15: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 Mar 12 16:12:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 08:12:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-701836 ] Thread running (os.system or popen#) Message-ID: Bugs item #701836, was opened at 2003-03-11 22:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik Öhman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: Thread running (os.system or popen#) Initial Comment: Bottom line: Some programs may lock up when spawned from a thread. >>> import thread, os >>> thread.start_new_thread(os.system, ("/usr/sbin/ntpdate ifi.uio.no",)) This starts a program "ntpdate" from a Python thread. Usually this is no problem. Ntpdate, is a simple program to adjust the clock of the system. However, when ntpdate is started from a thread it locks up and newer exits!! With my limited debugging knowledge, it sems as it hangs in a "poll()" kernel call, however, this could be misleading. (I used stacktrace -p ) ---------------------------------------------------------------------- >Comment By: Johan Fredrik Öhman (johanfo) Date: 2003-03-12 17:12 Message: Logged In: YES user_id=556425 I have verified this bug on both Redhat 8.0 and SuSE 8.1, linux yes. Signal is one possible path, filedescriptors another. I read somwhere that there was some issues with pthreads forking and filedescriptors. However, this is not my area (too low level).... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-12 13:40 Message: Logged In: YES user_id=6656 IIRC, threads other than the main thread get a signal mask that blocks everything. That could be the problem, but I don't know what to do about it... What platform are you on? Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701836&group_id=5470 From noreply@sourceforge.net Wed Mar 12 16:14:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 08:14:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Raymond Hettinger (rhettinger) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-12 11:14 Message: Logged In: YES user_id=2138 I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2). In Python 2.3, widget.cget() will return ints in stead of strings where it needs to. My test code: import Tkinter a = Tkinter.Frame()['borderwidth'] print type(a), a Pmw assumes the return values of all cget calls will be strings. If there's a bug here, it's just that Pmw doesn't yet support Python 2.3. I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 17:39 Message: Logged In: YES user_id=80475 Corvus, did you have any luck finding the offending lines in PmW? Can this bug be posted on PmW's SF site and closed here or do you guys think something still needs to be fixed in Python? ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 16:57 Message: Logged In: YES user_id=454042 We don't see the problem in Python 2.1. In fact initially we fell back to 2.1 but I don't want to stay there. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 15:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 12 18:12:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 10:12:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) >Assigned to: Neal Norwitz (nnorwitz) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-12 13:12 Message: Logged In: YES user_id=80475 Neal,I saw that you've been maintaining _tkinter.c. Do you have time to look into the behavior change for widget.cget ()? It would be great if PmW could be kept working under Py2.3. Corvus, thanks for the precise bug report. I think it gets to the heart of the matter. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-12 11:14 Message: Logged In: YES user_id=2138 I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2). In Python 2.3, widget.cget() will return ints in stead of strings where it needs to. My test code: import Tkinter a = Tkinter.Frame()['borderwidth'] print type(a), a Pmw assumes the return values of all cget calls will be strings. If there's a bug here, it's just that Pmw doesn't yet support Python 2.3. I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 17:39 Message: Logged In: YES user_id=80475 Corvus, did you have any luck finding the offending lines in PmW? Can this bug be posted on PmW's SF site and closed here or do you guys think something still needs to be fixed in Python? ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 16:57 Message: Logged In: YES user_id=454042 We don't see the problem in Python 2.1. In fact initially we fell back to 2.1 but I don't want to stay there. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 15:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Thu Mar 13 06:27:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 12 Mar 2003 22:27:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug Message-ID: Bugs item #702775, was opened at 2003-03-13 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Nobody/Anonymous (nobody) Summary: dumbdbm __del__ bug Initial Comment: I used shelve.py and it falls back on dumbdbm when no possible alternatives are found on the system. I found this error, which is recurrent and deterministic: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error'" in > ignored The problem seems to reside in the __del__ of dumbdbm._Database: class _Database: ... def __del__(self): if self._index is not None: self._commit() ... def _commit(self): try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() My investigation showed that the error was from _commit. When it was called, _os or _open was both None. And the exception catch didn't work quite safely cause its in the "except" clause. The reason I suspect is when the time that _Database.__del__ was called the os module(which is imported as _os) is already removed out. I changed the code as: def _commit(self): global _os if _os is None: import os as _os import __builtin__ _open = __builtin__.open try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass ...... Now it works without any problems, AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 From noreply@sourceforge.net Thu Mar 13 10:14:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 02:14:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-702858 ] deepcopy can't copy self-referential new-style classes Message-ID: Bugs item #702858, was opened at 2003-03-13 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702858&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephen C Phillips (scp93ch) Assigned to: Nobody/Anonymous (nobody) Summary: deepcopy can't copy self-referential new-style classes Initial Comment: Given this code: import copy class Foo(object): pass f = Foo() f.bar = f g = copy.deepcopy(f) You will find with Python 2.3a2 and 2.2.2: f is f.bar -> True g is g.bar -> False g is not f -> True g.bar is not f -> True Obviously, all the statements should be True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702858&group_id=5470 From noreply@sourceforge.net Thu Mar 13 13:05:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 05:05:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python libraries. Message-ID: Bugs item #702157, was opened at 2003-03-12 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation of static/dynamic python libraries. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- >Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-13 13:05 Message: Logged In: YES user_id=732192 Uuuh when I say "python library" I mean a "python module" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Thu Mar 13 13:05:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 05:05:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python modules. Message-ID: Bugs item #702157, was opened at 2003-03-12 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) >Summary: No documentation of static/dynamic python modules. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-13 13:05 Message: Logged In: YES user_id=732192 Uuuh when I say "python library" I mean a "python module" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Thu Mar 13 16:40:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 08:40:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-703066 ] os.utime can fail with TypeError Message-ID: Bugs item #703066, was opened at 2003-03-13 08:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703066&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime can fail with TypeError Initial Comment: Occasionally os.utime can fail with a TypeError: # python Python 2.2.2 (#1, Dec 16 2002, 02:51:47) [GCC 3.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os,time >>> os.utime("/backup/test/interhost/ace/.maildir-sent/cur/rdiff-backup.tmp.1980", ... (time.time(), 1038064008)); Traceback (most recent call last): File "", line 2, in ? TypeError: utime() arg 2 must be a tuple (atime, mtime) if one of the elements in the time pair is a float and not a long. Strangely it seems to work sporadically. It may just be a documentation problem -- add a note in the docs saying longs are required, and then have the TypeError say: TypeError: utime() arg 2 must be a tuple of longs (atime, mtime) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703066&group_id=5470 From noreply@sourceforge.net Thu Mar 13 17:03:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 09:03:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug Message-ID: Bugs item #702775, was opened at 2003-03-13 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Nobody/Anonymous (nobody) Summary: dumbdbm __del__ bug Initial Comment: I used shelve.py and it falls back on dumbdbm when no possible alternatives are found on the system. I found this error, which is recurrent and deterministic: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error'" in > ignored The problem seems to reside in the __del__ of dumbdbm._Database: class _Database: ... def __del__(self): if self._index is not None: self._commit() ... def _commit(self): try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() My investigation showed that the error was from _commit. When it was called, _os or _open was both None. And the exception catch didn't work quite safely cause its in the "except" clause. The reason I suspect is when the time that _Database.__del__ was called the os module(which is imported as _os) is already removed out. I changed the code as: def _commit(self): global _os if _os is None: import os as _os import __builtin__ _open = __builtin__.open try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass ...... Now it works without any problems, AFAIK. ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2003-03-14 02:02 Message: Logged In: YES user_id=116941 see the thread at http://groups.google.com/groups? selm=ba1e306f.0303111337.72a696c7% 40posting.google.com , esp. by my name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 From noreply@sourceforge.net Thu Mar 13 17:22:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 09:22:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-452144 ] How to install some stuff to /usr/sbin Message-ID: Bugs item #452144, was opened at 2001-08-17 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: Nobody/Anonymous (nobody) Summary: How to install some stuff to /usr/sbin Initial Comment: I'd like behavior identical to "scripts" but want certain files to go to /usr/sbin instead of /usr/bin How can I accomplish this? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-03-13 17:22 Message: Logged In: YES user_id=6656 I was obviously lying when I said I'd look at this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 10:07 Message: Logged In: YES user_id=6656 I've been thinking build scripts needs to get a little smarter anyway. Will look at this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470 From noreply@sourceforge.net Thu Mar 13 20:35:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 12:35:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-703198 ] os.popen with mode "rb" fails on Unix Message-ID: Bugs item #703198, was opened at 2003-03-13 12:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703198&group_id=5470 Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: J. Peterson (isonno) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen with mode "rb" fails on Unix Initial Comment: On Windows, it's necessary to use the mode "rb" to open a binary stream to a process. On Unix the "b" modifier isn't necessary, but supplying it causes the popen call to fail with OSError: [Errno 22] Invalid argument The Unix version of popen should accept and simply ignore the "b" modifier to the mode, rather than fail. That way the same code can run on both platforms without modification or extra code to special case an OS that may need the "b" modifier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703198&group_id=5470 From noreply@sourceforge.net Fri Mar 14 06:34:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 13 Mar 2003 22:34:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-699934 ] Obscure error message Message-ID: Bugs item #699934, was opened at 2003-03-08 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Raymond Hettinger (rhettinger) Summary: Obscure error message Initial Comment: >>> class A(object): ... m = 1 ... >>> class B(A): pass ... >>> class C(A): pass ... >>> class D(A,B): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: MRO conflict among bases A, B I happen to know what MRO stands for, but probably most people that made the typo I did in the diamond inheritance graph will have no idea what they did wrong... How about "One of the declared superclasses A, B inherits from the other, the method resolution order (MRO) would therefore be undefined. Cannot create class." -- bjorn ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-14 01:34 Message: Logged In: YES user_id=80475 Idea 1 ------ TypeError: Cannot create class. Accessing superclasses A, B in order creates conflicting inheritance trees which leave the method resolution order (MRO) undefined. Idea 2 ------ Cannot create a consistent method resolution order (MRO) for bases A, B. Idea 3 ------ Doh! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-03-12 08:01 Message: Logged In: YES user_id=6656 Unfortunately the new error message makes no sense when you get it by rearranging __bases__. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 23:38 Message: Logged In: YES user_id=80475 Fixed. See: Objects/typeobject.c 2.216 Lib/test/test_descr.py 1.187 ---------------------------------------------------------------------- Comment By: Bjorn Pettersen (bpettersen) Date: 2003-03-11 21:50 Message: Logged In: YES user_id=556638 Even better. If I were to suggest anything, it would be to add "(lookup)" after "resolution" since that seems to be the more frequently used terminology -- not a big issue though. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 20:29 Message: Logged In: YES user_id=80475 I don't think the first part of the sentence is accurate. MRO conflicts can arise for less straight-forward reasons. How about: "Cannot create class. Superclasses A, B have conflicting inheritance trees which leave the method resolution order (MRO) undefined." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699934&group_id=5470 From noreply@sourceforge.net Fri Mar 14 15:08:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 07:08:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-703666 ] Several objects don't decref tmp on failure in subtype_new Message-ID: Bugs item #703666, was opened at 2003-03-14 10:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703666&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Several objects don't decref tmp on failure in subtype_new Initial Comment: Several objects have a something_subtype_new which creates a new object of a given subtype that if the subtype creation routine fails for any reason, returns NULL but leaves a temporary variable with a reference. The only normal reason this would occur is if you ran out of memory (in which case it wouldn't matter), but I don't think the core can predict that it knows that to be the only reason an unknown subtype might return NULL in it's alloc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703666&group_id=5470 From noreply@sourceforge.net Fri Mar 14 15:37:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 07:37:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-700651 ] Canvas origin is off-canvas in create_(). Workaround Message-ID: Bugs item #700651, was opened at 2003-03-10 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700651&group_id=5470 Category: Tkinter Group: Python 2.2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Canvas origin is off-canvas in create_(). Workaround Initial Comment: The origin for x,y pairs sent to the Canvas items is off-screen by the sum of borderwidth bd and highlightthickness hT. The accompanying program shows this and includes three functions which can be used in workarounds. I just hope the upload facility works this time. A canvas with exaggerated values for bd and hT is shown to illustrate the problem. On it, a full-screen open rectangle ((0-to width-1) by 0-to-(height-1)) is shown in red, and it is partly off-screen. A blue rectangle of the same coordinates is sent through UsrToCnv(), which uses .cget() to fetch up-to-date values for bd and hT (which can of course be updated on the fly) and translates the user's canvas item back where it belongs. Clicking on the canvas illustrates the use of CnvToUsr, sending a tuple (event.x, event.y) through the reverse of the above translation so that it matches the user's expectations. If these functions or their equivalents are not already available, you have my permission to offer these as workarounds while someone investigates the problem. I recommend that similar trials be performed on Tcl/Tk or PERL/Tk to see if the problem lies in Tkinter or even deeper in the mass of code. I'm a Python beginner so can't help with a project to fix it, but I'd like to be kept informed of any progress or decisions, if that's not too much trouble. Roy Keir ps I got the "no data in the file" message again. If you will send me another URL or give me a PO address, I'll send the file by that more reliable path fyi, I use Netscape 4.7 Does that correlate with upload failures ? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 10:37 Message: Logged In: YES user_id=11375 Duplicate of #700650; closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700651&group_id=5470 From noreply@sourceforge.net Fri Mar 14 15:45:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 07:45:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris Message-ID: Bugs item #700780, was opened at 2003-03-10 06:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Iain Morrison (iainmorrison) Assigned to: Nobody/Anonymous (nobody) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 10:45 Message: Logged In: YES user_id=11375 Your compiler may not be looking in /usr/local/ for headers and libraries. You shouldn't install ncurses over Solaris curses; locally-installed software belongs in /usr/local/, period. When you run the configure script, you can supply environment variables to add compiler flags; run configure --help to see a list. I'd suggest something like 'CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure', and see if it picks up ncurses.h then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 From noreply@sourceforge.net Fri Mar 14 16:04:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 08:04:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: Bugs item #678723, was opened at 2003-02-01 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 I can replicate this problem on my Debian machine. config.log attached. 'gcc -o conftest -g -O2 config.c -lpth -lrt -ldl' reports the following error: '/usr/bin/ld: cannot find -lpth'. This is very odd, because I've got the libpth14 package installed, there's a .so in /usr/lib, ldconfig find it, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 10:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-01 20:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 13:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Fri Mar 14 16:04:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 08:04:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: Bugs item #678723, was opened at 2003-02-01 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 I can replicate this problem on my Debian machine. config.log attached. 'gcc -o conftest -g -O2 config.c -lpth -lrt -ldl' reports the following error: '/usr/bin/ld: cannot find -lpth'. This is very odd, because I've got the libpth14 package installed, there's a .so in /usr/lib, ldconfig find it, etc. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 Let's try that attachment again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 10:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-01 20:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 13:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Fri Mar 14 18:52:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 10:52:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-703779 ] strange warnings messages in interpreter Message-ID: Bugs item #703779, was opened at 2003-03-14 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703779&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: strange warnings messages in interpreter Initial Comment: If the PYTHONSTARTUP environment variable is used, warnings will look strange. The warnings module uses __file__ to try to find the line causing the warning and print it out. __file__ is never reset after being set when processing the startup file. The attached patch fixes this by changing PyRun_SimpleFileExFlags to unset __file__ in the __main__ module dictionary entry after running a file, when it had been set by the routine in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703779&group_id=5470 From noreply@sourceforge.net Fri Mar 14 21:33:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 14 Mar 2003 13:33:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: Bugs item #678723, was opened at 2003-02-01 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-14 22:33 Message: Logged In: YES user_id=21627 Can you give the precise name of the .so file you have in /usr/lib? If it is usr/lib/libpth.so.14, then it is irrelevant that ldconfig finds it: /usr/bin/ld won't use that file for linking. You probably need to install libpth-dev. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 17:04 Message: Logged In: YES user_id=11375 I can replicate this problem on my Debian machine. config.log attached. 'gcc -o conftest -g -O2 config.c -lpth -lrt -ldl' reports the following error: '/usr/bin/ld: cannot find -lpth'. This is very odd, because I've got the libpth14 package installed, there's a .so in /usr/lib, ldconfig find it, etc. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 17:04 Message: Logged In: YES user_id=11375 Let's try that attachment again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 16:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-02 02:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 19:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:11:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:11:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: Bugs item #678723, was opened at 2003-02-01 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-03-15 08:11 Message: Logged In: YES user_id=11375 Good suggestion; installing libpth-dev lets configure run without problems. So the simplest fix for this bug is probably just adding a note to the README warning people to have the appropriate .so installed. Or should configure check for a linkable libfoo.so? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-14 16:33 Message: Logged In: YES user_id=21627 Can you give the precise name of the .so file you have in /usr/lib? If it is usr/lib/libpth.so.14, then it is irrelevant that ldconfig finds it: /usr/bin/ld won't use that file for linking. You probably need to install libpth-dev. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 I can replicate this problem on my Debian machine. config.log attached. 'gcc -o conftest -g -O2 config.c -lpth -lrt -ldl' reports the following error: '/usr/bin/ld: cannot find -lpth'. This is very odd, because I've got the libpth14 package installed, there's a .so in /usr/lib, ldconfig find it, etc. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 11:04 Message: Logged In: YES user_id=11375 Let's try that attachment again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 10:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-01 20:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 13:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:24:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:24:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-678723 ] ./configure fails w/error: cannot compute sizeof (wchar_t), Message-ID: Bugs item #678723, was opened at 2003-02-01 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Duplicate Priority: 5 Submitted By: Jeff Stephens (jeffste) Assigned to: Nobody/Anonymous (nobody) Summary: ./configure fails w/error: cannot compute sizeof (wchar_t), Initial Comment: I am running RH 7.3, kernel 2.4.18-19.7.x, and gcc-2.96-113. I attempted to configure python-2.3a1 as follows: ./configure --enable-shared --with-threads --with-pth Got the following error: checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:24 Message: Logged In: YES user_id=21627 Feel free to put a note into the README. However, I think this is a pilot error: If the user specifies --with-pth, but does not have pth properly installed, then configure is entitled to fail in strange ways. If --with or --enable is specified, it should be taken as overriding whatever configure thinks is right, so those command options must be followed blindly. Perhaps a general note "read config.log if configure fails" would be appropriate. It would be good if Jeff could report whether he ran into the same problem (pth not properly installed). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-15 14:11 Message: Logged In: YES user_id=11375 Good suggestion; installing libpth-dev lets configure run without problems. So the simplest fix for this bug is probably just adding a note to the README warning people to have the appropriate .so installed. Or should configure check for a linkable libfoo.so? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-14 22:33 Message: Logged In: YES user_id=21627 Can you give the precise name of the .so file you have in /usr/lib? If it is usr/lib/libpth.so.14, then it is irrelevant that ldconfig finds it: /usr/bin/ld won't use that file for linking. You probably need to install libpth-dev. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 17:04 Message: Logged In: YES user_id=11375 I can replicate this problem on my Debian machine. config.log attached. 'gcc -o conftest -g -O2 config.c -lpth -lrt -ldl' reports the following error: '/usr/bin/ld: cannot find -lpth'. This is very odd, because I've got the libpth14 package installed, there's a .so in /usr/lib, ldconfig find it, etc. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 17:04 Message: Logged In: YES user_id=11375 Let's try that attachment again. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-05 16:42 Message: Logged In: YES user_id=21627 It would be good if you could attach the config.log that you got when it failed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-02 02:46 Message: Logged In: YES user_id=33168 Jeff, I think we should try to fix this. It looks like a duplicate of 662840. It would be great if you can help debug this further. The problem seems to be related to redhat 7.3. The other bug which fails exactly the same way is using gcc 3.2 and doesn't mention config options (although they may be used). ---------------------------------------------------------------------- Comment By: Jeff Stephens (jeffste) Date: 2003-02-01 19:33 Message: Logged In: YES user_id=702289 I reran ./configure several times, varying the options, and found that this error only occurs when the option "--with-pth" is included. For example: ./configure --enable-shared --with-pth #error occurs ./configure --enable-shared --with-threads #error does NOT occur I don't know whether this is a bug or not, so I am leaving it to the experts to say yea or nay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678723&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:29:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:29:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python modules. Message-ID: Bugs item #702157, was opened at 2003-03-12 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation of static/dynamic python modules. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:29 Message: Logged In: YES user_id=21627 What do you mean when you say "all dynamic libraries got dynamically linked into the Python interpreter"? If it means what I understand it means (i.e. all libraries are passed to the ld command creating the python binary), then this is not supposed to happen. Can you provide a make log to demonstrate this more clearly? ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-13 14:05 Message: Logged In: YES user_id=732192 Uuuh when I say "python library" I mean a "python module" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:33:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:33:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:41:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:41:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-701823 ] configure option --enable-shared make problems Message-ID: Bugs item #701823, was opened at 2003-03-11 22:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701823&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Uwe Hoffmann (qual) >Assigned to: Martin v. Löwis (loewis) Summary: configure option --enable-shared make problems Initial Comment: on building python 2.3.a2 with the following lines ./configure --prefix=/tmp/python --enable-shared --with-cxx=g++ --with-signal-module --with-threads ; make ; make install; the installed python interpreter cann't be started because libpython2.3.so.1.0 is installed but not libpython2.3.so . the attached patch works in my environment. Linux ; glibc 2.2.5; gcc 3.2; binutils 2.13 at least solaris should suffer from the same problem. (the change for configure.in is not tested, the changes were directly made to configure) the same can be achieved if libpython$(VERSION)$(SO) (actually libpython2.3.so ) is installed and not $(INSTSONAME) ( actually libpython2.3.so.1.0) . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701823&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:38:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:38:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-699068 ] Error using Tkinter embeded in C++ Message-ID: Bugs item #699068, was opened at 2003-03-07 00:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699068&group_id=5470 Category: Tkinter Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: John (johnnoone) Assigned to: Nobody/Anonymous (nobody) Summary: Error using Tkinter embeded in C++ Initial Comment: Using Python 2.2.2 on MS Windows 2000 platform. Calling embedded Python from Visual C++ works fine until I add a call to Tkinter (version 8.3). Follow the example in section 5.3 at the following link: http://www.python.org/doc/ext/extending-with- embedding.html Link call.cpp as is and add a line to multiply.py to create a Tkinter frame: "fr = Tkinter.Tk()" // added import for Tkinter too! Yields the following error messages: C:\Python22\c\vcpp\hello3>hello3 call multiply 2 3 Thy shall add 2 times 3 Traceback (most recent call last): File "C:\Python22\c\vcpp\hello3\call.py", line 7, in multiply fr = Tk() File "C:\Python22\lib\lib-tk\Tkinter.py", line 1491, in __init__ baseName = os.path.basename(sys.argv[0]) AttributeError: 'module' object has no attribute 'argv' Call failed Is there a problem using Tkinter from C++? Python/Tk work fine standalone. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:38 Message: Logged In: YES user_id=21627 Please look at the source of sysmodule.c. sys.argv is only present if PySys_SetArgv is invoked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699068&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:44:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:44:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris Message-ID: Bugs item #700780, was opened at 2003-03-10 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Iain Morrison (iainmorrison) Assigned to: Nobody/Anonymous (nobody) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:44 Message: Logged In: YES user_id=21627 Did you expect to use ncurses, or did you mean to use curses? What is the ncurses portion of running setup.py? To eliminate setup.py problems, you can always edit Modules/Setup. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 16:45 Message: Logged In: YES user_id=11375 Your compiler may not be looking in /usr/local/ for headers and libraries. You shouldn't install ncurses over Solaris curses; locally-installed software belongs in /usr/local/, period. When you run the configure script, you can supply environment variables to add compiler flags; run configure --help to see a list. I'd suggest something like 'CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure', and see if it picks up ncurses.h then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 From noreply@sourceforge.net Sat Mar 15 13:45:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 05:45:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-699312 ] builtin type inconsistency Message-ID: Bugs item #699312, was opened at 2003-03-07 11:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: builtin type inconsistency Initial Comment: many builtin types can be called without arguments, yielding the 'false' (zero/empty) instance of their type. However, others can't. why is int()==0 but calling bool() raises an exception rather than returning False? I consider this irregularity a tiny bug. Arguably slice() should also return the same result as slice(None), again for regularity, but this is admittedly iffier. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:45 Message: Logged In: YES user_id=21627 I agree this is a bug, also I personally would not care enough to fix it. Would you like to work on a patch? I guess if your observation is a principle to be followed, it needs to be documented, also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699312&group_id=5470 From noreply@sourceforge.net Sat Mar 15 16:21:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 08:21:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-704174 ] Memory leak: threading.Thread.__init__(self, target=self.xx) Message-ID: Bugs item #704174, was opened at 2003-03-15 16:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704174&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Darrell Gallion (dgallion) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak: threading.Thread.__init__(self, target=self.xx) Initial Comment: This call threading.Thread.__init__(self, target=self.xxx) makes this assignment self.__target = target Which looks like a circular refrence to me. weakref anyone ? The following test code shows the leak in action. --Darrell import threading, time class T1(threading.Thread): def __init__(self, leak=0): self.leak=leak if leak: threading.Thread.__init__(self, target=self.m1) else: threading.Thread.__init__(self) self.start() def run(self): pass def m1(self): pass def __del__(self): print 'DEL:', self, "leak:",self.leak for x in range(10): T1(leak=1) for x in range(10): T1() time.sleep(1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704174&group_id=5470 From noreply@sourceforge.net Sat Mar 15 16:44:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 08:44:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx) Message-ID: Bugs item #704180, was opened at 2003-03-15 16:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Darrell Gallion (dgallion) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak: threading.Thread.__init__(self, target=self.xx) Initial Comment: This call threading.Thread.__init__(self, target=self.xxx) makes this assignment self.__target = target Which looks like a circular refrence to me. weakref anyone ? The following test code shows the leak in action. --Darrell import threading, time class T1(threading.Thread): def __init__(self, leak=0): self.leak=leak if leak: threading.Thread.__init__(self, target=self.m1) else: threading.Thread.__init__(self) self.start() def run(self): pass def m1(self): pass def __del__(self): print 'DEL:', self, "leak:",self.leak for x in range(10): T1(leak=1) for x in range(10): T1() time.sleep(1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470 From noreply@sourceforge.net Sat Mar 15 17:19:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 09:19:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-704194 ] Problems printing and sleep Message-ID: Bugs item #704194, was opened at 2003-03-15 12:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704194&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: ross (zepplin) Assigned to: Nobody/Anonymous (nobody) Summary: Problems printing and sleep Initial Comment: When I do the following: gui = input("Whats your name?") print gui Sleep(1000) I can input my name, but the program then closes. Are there any includes or return 0's like in C++? Could the above code be my entire program? It seems like I need to start or end the program somehow... Well thanks, sorry if the answer to this is already here. I didn't see anything like it. And where are the forums? Thanks again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704194&group_id=5470 From noreply@sourceforge.net Sun Mar 16 04:39:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 20:39:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx) Message-ID: Bugs item #704180, was opened at 2003-03-15 11:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Darrell Gallion (dgallion) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak: threading.Thread.__init__(self, target=self.xx) Initial Comment: This call threading.Thread.__init__(self, target=self.xxx) makes this assignment self.__target = target Which looks like a circular refrence to me. weakref anyone ? The following test code shows the leak in action. --Darrell import threading, time class T1(threading.Thread): def __init__(self, leak=0): self.leak=leak if leak: threading.Thread.__init__(self, target=self.m1) else: threading.Thread.__init__(self) self.start() def run(self): pass def m1(self): pass def __del__(self): print 'DEL:', self, "leak:",self.leak for x in range(10): T1(leak=1) for x in range(10): T1() time.sleep(1) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-15 23:39 Message: Logged In: YES user_id=31435 The "leak" is due to that you gave this class a __del__ method: cyclic garbage collection won't magically reclaim objects in cycles with __del__ methods. Remove the __del__ and you can run this all day without the process size growing. If you leave the __del__ in, you can find all your uncollectible thread objects in gc.garbage (and use that to break the cycles and get them collected, if you like -- I'd recommend not using __del__ at all, though). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470 From noreply@sourceforge.net Sun Mar 16 16:45:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Mar 2003 08:45:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx) Message-ID: Bugs item #704180, was opened at 2003-03-15 16:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Darrell Gallion (dgallion) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak: threading.Thread.__init__(self, target=self.xx) Initial Comment: This call threading.Thread.__init__(self, target=self.xxx) makes this assignment self.__target = target Which looks like a circular refrence to me. weakref anyone ? The following test code shows the leak in action. --Darrell import threading, time class T1(threading.Thread): def __init__(self, leak=0): self.leak=leak if leak: threading.Thread.__init__(self, target=self.m1) else: threading.Thread.__init__(self) self.start() def run(self): pass def m1(self): pass def __del__(self): print 'DEL:', self, "leak:",self.leak for x in range(10): T1(leak=1) for x in range(10): T1() time.sleep(1) ---------------------------------------------------------------------- >Comment By: Darrell Gallion (dgallion) Date: 2003-03-16 16:45 Message: Logged In: YES user_id=68151 I know about the __del__ issue with gc, and your right this example worked fine with it removed. The much larger app that sent me on this chase wasn't fixed by the __del__ method. Yet it was fixed by moving the target method to a function call instead of a method on the object. It's a large app and the timing of when an object is destroyed matters. The following helps me see my problem. import threading, time, weakref class T1(threading.Thread): def __init__(self): self.go=1 threading.Thread.__init__(self, target=self.m1) self.start() def m1(self): while self.go: time.sleep(0.0001) objs={} while 1: t1 = weakref.ref(T1()) objs[t1]=1 t1().go=0 time.sleep(0.01) for o in objs.keys(): if o() == None: del objs[o] print len(objs), ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-16 04:39 Message: Logged In: YES user_id=31435 The "leak" is due to that you gave this class a __del__ method: cyclic garbage collection won't magically reclaim objects in cycles with __del__ methods. Remove the __del__ and you can run this all day without the process size growing. If you leave the __del__ in, you can find all your uncollectible thread objects in gc.garbage (and use that to break the cycles and get them collected, if you like -- I'd recommend not using __del__ at all, though). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470 From noreply@sourceforge.net Sun Mar 16 20:57:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Mar 2003 12:57:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads? Message-ID: Bugs item #704641, was opened at 2003-03-16 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: _tkinter.c won't build w/o threads? Initial Comment: I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but... Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin. For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined. And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop(). And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 From noreply@sourceforge.net Sun Mar 16 23:07:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 16 Mar 2003 15:07:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-690622 ] test_cpickle overflows stack on MacOS9 Message-ID: Bugs item #690622, was opened at 2003-02-21 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690622&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_cpickle overflows stack on MacOS9 Initial Comment: Test_cpickle overflows the stack and hangs the interpreter on MacOS9. This happens in test_nonrecursive_deep(), in the dumps() call. I think there's a PyOS_CheckStack() call missing somewhere in cPickle. Also, it's probably a good idea to lower the recursion to 50 (the test passes as long as the recusrion is less than 65 deep), at least on MacOS9. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-17 00:07 Message: Logged In: YES user_id=45365 It passes now. Closing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-21 21:24 Message: Logged In: YES user_id=31435 I reduced the nesting depth to 60, in Lib/test/test_cpickle.py, rev 1.14. Jack, please close this bug as Fixed if your problem goes away now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-21 21:04 Message: Logged In: YES user_id=31435 Right, AFAICT 60 is enough to test what this is trying to test (although I'm not the "fast pickler" expert -- but I think it's clear enough). Jack, please confirm that 60 is OK for you? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-21 21:01 Message: Logged In: YES user_id=6380 I agree that I'd rather not see CheckStack calls added to cPickle. But using 60 instead of 100 should work for both of you, right? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-21 20:55 Message: Logged In: YES user_id=31435 There are no PyOS_CheckStack() calls in cPickle, and I'm not sure anyone really wants to bother adding them (cPickle is meant to be high-performance, not safe ). That test is consuming more stack frames than it used to, because each level of list pickling now bites another stack frame to call the new "batch list elements" routine. Reducing to 50 doesn't fly because cPickle's internal PY_CPICKLE_FAST_LIMIT #define happens to be 50 now, and the purpose of test_nonrecursive_deep is to be sure that non-cyclic containers get pickled OK in a "fast" pickler even if they're nested as deeply as PY_CPICKLE_FAST_LIMIT. Assigning to Guido for further cogitation on his day off . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690622&group_id=5470 From noreply@sourceforge.net Mon Mar 17 11:07:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 03:07:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-702180 ] PackageManager can silently ignore errors Message-ID: Bugs item #702180, was opened at 2003-03-12 14:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702180&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager can silently ignore errors Initial Comment: If verbose is off and a build fails then PackageManager silently ignores the error, in stead of giving at least some feedback to the user. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-17 12:07 Message: Logged In: YES user_id=45365 Fixed in pimp.py rev. 1.14. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702180&group_id=5470 From noreply@sourceforge.net Mon Mar 17 11:13:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 03:13:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-602291 ] Bgen should learn about booleans Message-ID: Bugs item #602291, was opened at 2002-08-30 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602291&group_id=5470 Category: Macintosh Group: None Status: Open >Resolution: Later Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Bgen should learn about booleans Initial Comment: Bgen should be taught about booleans, and the various Mac toolbox modules too. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-17 12:13 Message: Logged In: YES user_id=45365 This will have to wait until PyArg_Parse and Py_BuildValue understand about booleans. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602291&group_id=5470 From noreply@sourceforge.net Mon Mar 17 11:09:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 03:09:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-704919 ] Problems building python with tkinter on HPUX... Message-ID: Bugs item #704919, was opened at 2003-03-17 12:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: Problems building python with tkinter on HPUX... Initial Comment: I have some problems when trying to install python on a HPUX 10.20 system. All seems to go well during the compiling and during the installation process, but when I try to use tkinter in my new python with an "import _tkinter", i have the following lines : Python 2.2.2 (#2, Mar 17 2003, 04:36:02) [GCC 2.95.2 19991024 (release)] on hp-ux10 Type "help", "copyright", "credits" or "license" for more information. >>> import _tkinter /usr/lib/dld.sl: Unresolved symbol: acos (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: asin (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: atan (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: cosh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: log10 (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: sinh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: tan (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: tanh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclTraceExec (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclProcBodyType (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclFreeObjList (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclExecutableName (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: Tcl_FindExecutable (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl zsh: abort (core dumped) python I have a python1.5/tkinter that works with tcl/tk 8.0p2... When trying to compile with this version of tcl/tk, i had errors with the tkinter module compilation. Then, I tried to compile a tcl/tk 8.4.2, or even use a binary-package of a tcl/tk 8.2.1, but in both cases I have the above errors when running... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470 From noreply@sourceforge.net Mon Mar 17 11:49:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 03:49:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 11:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx= flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 13:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Mon Mar 17 12:02:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 04:02:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python modules. Message-ID: Bugs item #702157, was opened at 2003-03-12 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation of static/dynamic python modules. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- >Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 12:02 Message: Logged In: YES user_id=732192 Hi, When I build python with zlib and the commented shared flag "#*shared*". then zlib.so is included in ./python (checked with ldd ./python). When I build python with zlib and the *shared* flag commented out then is zlib.so not part of the ./python program. The question is now: is this the difference between shared and static modules? or do I have so weird problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 13:29 Message: Logged In: YES user_id=21627 What do you mean when you say "all dynamic libraries got dynamically linked into the Python interpreter"? If it means what I understand it means (i.e. all libraries are passed to the ld command creating the python binary), then this is not supposed to happen. Can you provide a make log to demonstrate this more clearly? ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-13 13:05 Message: Logged In: YES user_id=732192 Uuuh when I say "python library" I mean a "python module" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Mon Mar 17 12:24:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 04:24:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 12:24 Message: Logged In: YES user_id=732192 For example.......... The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGS C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 11:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx= flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 13:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Mon Mar 17 14:40:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 06:40:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-704996 ] HTMLParser fails on Message-ID: Bugs item #704996, was opened at 2003-03-17 09:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704996&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: gary aviv (aaii1025) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser fails on Initial Comment: HTMLParser can't handle constructs such as: ... which is found in MS Word documents saved as HTML. The problem is in markupbase.py Suggest the follwoing patch: diff -u /usr/local/lib/python2.2/markupbase.py.orig /usr/local/lib/python2.2/markupbase.py --- /usr/local/lib/python2.2/markupbase.py.orig Mon Mar 17 09:23:17 2003 +++ /usr/local/lib/python2.2/markupbase.py Mon Mar 17 09:26:45 2003 @@ -3,7 +3,8 @@ import re import string -_declname_match = re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*').match +#_declname_match = re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*').match # was this +_declname_match = re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*|\[.*\]').match # replace by this _declstringlit_match = re.compile(r'(\'[^\']*\'|"[^"]*")\s*').match del re @@ -73,7 +74,7 @@ if c == ">": # end of declaration syntax data = rawdata[i+2:j] - if decltype == "doctype": + if decltype == "doctype" or decltype[0] == '[': # handle self.handle_decl(data) else: self.unknown_decl(data) @@ -310,7 +311,7 @@ return string.lower(name), m.end() else: self.updatepos(declstartpos, i) - self.error("expected name token") + self.error("expected name token '%s'" % rawdata[i:i+10]) # improve error message # To be overridden -- handlers for unknown objects def unknown_decl(self, data): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704996&group_id=5470 From noreply@sourceforge.net Mon Mar 17 14:59:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 06:59:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-705005 ] python-mode.el: sexp commands don't understand Python Message-ID: Bugs item #705005, was opened at 2003-03-17 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705005&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ed Avis (epaepa) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el: sexp commands don't understand Python Initial Comment: Emacs has a whole lot of commands dealing with 'sexps', such as forward-sexp and kill-sexp. These originated with Lisp but are useful for other languages too. For example in c-mode, editing the text if (x > 7) { puts("hello"); } with point before the 'i', pressing M-C-k (kill-sexp) will first kill the 'if' keyword, leaving: (x > 7) { puts("hello"); } Then a second press of M-C-k leaves { puts("hello"); } and a third press kills the whole block following. So you can kill the whole if-statement, and nothing more, with three keypresses. This is useful for moving chunks of code around. However the same doesn't work in python-mode because Emacs doesn't appear to know about the definition of a sexp. You can kill balanced expressions on a particular line but it's not possible to remove the whole of an 'if' or 'while' block. Along the same lines, while commands like mark-defun work in most languages to select the current function definition, they don't work with Python's 'def' blocks, instead highlighting the whole file. Is it possible to get these and similar commands working, or is Emacs hardwired to look for starting and ending delimiters around each block? If it's not possible to make these commands work correctly, it might be better to disable them for python-mode rather than leave them present but wrong (eg mark-defun marks the whole buffer). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705005&group_id=5470 From noreply@sourceforge.net Mon Mar 17 15:18:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 07:18:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-703666 ] Several objects don't decref tmp on failure in subtype_new Message-ID: Bugs item #703666, was opened at 2003-03-14 10:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703666&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Several objects don't decref tmp on failure in subtype_new Initial Comment: Several objects have a something_subtype_new which creates a new object of a given subtype that if the subtype creation routine fails for any reason, returns NULL but leaves a temporary variable with a reference. The only normal reason this would occur is if you ran out of memory (in which case it wouldn't matter), but I don't think the core can predict that it knows that to be the only reason an unknown subtype might return NULL in it's alloc. ---------------------------------------------------------------------- >Comment By: Christopher A. Craig (ccraig) Date: 2003-03-17 10:18 Message: Logged In: YES user_id=135050 Apparently upload didn't take the first time ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703666&group_id=5470 From noreply@sourceforge.net Mon Mar 17 15:58:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 07:58:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-661521 ] plat-mac not on sys.path Message-ID: Bugs item #661521, was opened at 2003-01-03 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661521&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: plat-mac not on sys.path Initial Comment: The new plat-mac subdirectory of Lib should be on sys.path by default. It's currently only added for framework builds by means of a *.pth file, but it should be available on any OSX build, even with python -S, so some Makefile/Setup editing is neccesary. I tried to do it myself but I can't; Setup/Makefile editing is a field I definitely do not master. Jack offered to do it, but if anyone else can help us out here before he gets round to it (he's currently caught up with MacPython 2.3a1 for MacOS9), that would be even better. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-03-17 16:58 Message: Logged In: YES user_id=45365 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661521&group_id=5470 From noreply@sourceforge.net Mon Mar 17 18:29:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:29:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-705120 ] imap docs: s/criterium/criterion/ Message-ID: Bugs item #705120, was opened at 2003-03-17 18:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705120&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Pomraning (pilcrow) Assigned to: Nobody/Anonymous (nobody) Summary: imap docs: s/criterium/criterion/ Initial Comment: At least in English, the usually accepted singular of "criteria" is "criterion," not "criterium," which is something else entirely. Noticed in the imaplib docs and imaplib.py search() docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705120&group_id=5470 From noreply@sourceforge.net Mon Mar 17 18:39:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:39:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 19:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 13:24 Message: Logged In: YES user_id=732192 For example.......... The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGS C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 12:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx= flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Mon Mar 17 18:50:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:50:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-675420 ] email.Header() encoding does not work properly Message-ID: Bugs item #675420, was opened at 2003-01-27 08:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Pending Resolution: None Priority: 3 Submitted By: Andreas Jung (ajung) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header() encoding does not work properly Initial Comment: CMFCollectorNG uses email.Header() to encode the Subject of notification emails. In some case we discovered that Evolution and Mutt displayed an empty subject. The Subject "[CMFCollectorNG] #31 (Comment): noch: ein test" is converted to Subject: =?iso-8859-1?q?=5BCMFCollectorNG=5D_=2331_=28Comment=29=3A_ein=3A_test?= The problem seems to occur if there is more than one colon inside the subject. Mailings with "[CMFCollectorNG] #31 (Comment): noch ein test" as subject are recognized by the mail readers and being displayed. Upgrading to the latest email packages from the Python HEAD did not solve the problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-17 13:50 Message: Logged In: YES user_id=12800 Moving this to pending for auto-close if no further updates are provided. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-06 01:26 Message: Logged In: YES user_id=12800 I don't understand. Where's the email package error? It seems like you're complaining about some MUA bugs. Can you upload (not paste) a Python code sample that illustrates the bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 From noreply@sourceforge.net Mon Mar 17 18:51:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:51:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-702157 ] No documentation of static/dynamic python modules. Message-ID: Bugs item #702157, was opened at 2003-03-12 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation of static/dynamic python modules. Initial Comment: Hi, This problem cost me very much time to solve: After I build Python, all dynamic libraries got dynamically linked into the Python interpreter (libraries like zlib and tcl/tk stuff). I coudn't find out why this is, I only want to load zlib.so when I do a "import zlib" and not when I start Python. And this is (I think) the difference between statically and dynamically build Python libraries, but this isn't explaind in a clear way. You can configure the dynamic/static module beheviour in the Modules/Setup file (afher you did a configure) with the *shared* flag. The dinamic/static module behaviour should at least very clear described in that file, this is not the case at this moment. Best regards, Jan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 19:51 Message: Logged In: YES user_id=21627 I cannot reproduce this. If I leave # *shared*, but enable zlib in Modules/Setup, I get no file Modules/zlib.so, only Modules/zlib.o. This is incorporated into python. If I also leave zlib commented in Modules/Setup, zlib.so is build through setup.py in build/lib-somewhere, *after* python was linked. Can you provide a complete build log? ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 13:02 Message: Logged In: YES user_id=732192 Hi, When I build python with zlib and the commented shared flag "#*shared*". then zlib.so is included in ./python (checked with ldd ./python). When I build python with zlib and the *shared* flag commented out then is zlib.so not part of the ./python program. The question is now: is this the difference between shared and static modules? or do I have so weird problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:29 Message: Logged In: YES user_id=21627 What do you mean when you say "all dynamic libraries got dynamically linked into the Python interpreter"? If it means what I understand it means (i.e. all libraries are passed to the ld command creating the python binary), then this is not supposed to happen. Can you provide a make log to demonstrate this more clearly? ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-13 14:05 Message: Logged In: YES user_id=732192 Uuuh when I say "python library" I mean a "python module" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702157&group_id=5470 From noreply@sourceforge.net Mon Mar 17 18:51:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:51:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-705120 ] imap docs: s/criterium/criterion/ Message-ID: Bugs item #705120, was opened at 2003-03-17 19:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705120&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Pomraning (pilcrow) >Assigned to: Martin v. Löwis (loewis) Summary: imap docs: s/criterium/criterion/ Initial Comment: At least in English, the usually accepted singular of "criteria" is "criterion," not "criterium," which is something else entirely. Noticed in the imaplib docs and imaplib.py search() docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705120&group_id=5470 From noreply@sourceforge.net Mon Mar 17 18:50:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:50:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-699600 ] MIMEText's c'tor adds unwanted trailing newline to text Message-ID: Bugs item #699600, was opened at 2003-03-07 15:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIMEText's c'tor adds unwanted trailing newline to text Initial Comment: I have a web form that includes a "file" type . This means that it expects the HTTP POST data to be of type multipart/form-data. I was using the 'email' package to build this Message essentially like this: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(content) message.attach() this results in a message body (headers removed) like the following: --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="logfile"; filename="D:\trentm\tmp\seuss.txt" one fish two fish three fish blue fish --===============25164547096797829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: form-data; name="name" pliers --===============25164547096797829==-- The problem is those extra newlines after "blue fish" and after "pliers". My uploaded file "D:\trentm\tmp\seuss.txt" does not have a newline at the end. The result is that the file is changed (albeit slightly) on an HTTP upload. If I use IE6 or Mozilla 1.3 to file out this web form the multipart/form-data messages they generate do NOT include those extra newlines. The newlines were added by this code in the MIMEText's constructor: if text[-1] <> '\n': text += '\n' which has been around for a long time: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/mimelib/mimelib/mimelib/Text.py.diff? r1=1.1&r2=1.2 No real reason was given for adding this code, and it seems hard to defend it because if I change the above to the following I do not get the extra newlines: message = MIMEMultipart(_subtype="form-data") # for each non-file input part = MIMEText(None) part.set_payload(partValue) message.attach(part) # for each file input content = open(filename, 'rb).read() part = MIMEText(None) part.set_payload(content) message.attach() I suppose it is possible that there is a backward compatibility issue in changing this behaviour. You would be a better judge of that impact, Barry. Perhaps you could kill two birds with one stone and deprecate MIMEText in favor of a newly named one that drops the already deprecated _encoding argument as well. Cheers, Trent ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-17 13:50 Message: Logged In: YES user_id=12800 We decided to remove the \n since the mimelib crowd could find no instances of broken code. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-10 12:22 Message: Logged In: YES user_id=12800 I believe this was added to make sure that when a MIMEText was a subpart, the missing newline wouldn't break the appending of the boundary text. But we've since fixed that breakage in another way, so I think the code in MIMEText is wrong. Eliminating it breaks a bunch of unit tests but they appear easily reparable. The b/w compat issues are tougher since there may indeed be code relying on this. I don't want to deprecate the whole MIMEText class. Maybe the least painful is to add an argument to decide whether to add the newline or not. I'll bring this up on mimelib-devel and see what the consensus is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699600&group_id=5470 From noreply@sourceforge.net Mon Mar 17 19:30:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 11:30:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 19:30 Message: Logged In: YES user_id=732192 It becomes clear for me that making a good help for all systems out there is very difficult. But I could create a better ./configure --help output for python that is comon for all systems. And I can create a patch for the README file that explains the libstdc++ dependencies if you are building with GNU C++. Can I simply add a patch for these to the patch list or how does it work? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 18:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 12:24 Message: Logged In: YES user_id=732192 For example.......... The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGS C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 11:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx= flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 13:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Mon Mar 17 21:49:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 13:49:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: Bugs item #705231, was opened at 2003-03-17 21:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Mon Mar 17 22:06:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 14:06:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion failed, python aborts Message-ID: Bugs item #705231, was opened at 2003-03-17 16:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Anze Slosar (anze) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed, python aborts Initial Comment: This bug is reproducible with python 2.2.1 althogh it fails only occasionally as the flow depends on random numbers. It aborts by saying: python: Objects/floatobject.c:582: float_pow: Assertion `(*__errno_location ()) == 34' failed. Aborted I tried python 2.2.2 but as I try to install rpms I run into every growing list of dependencies. I couldn't reproduce the exact cause of the bug, but it is caused by the following simple code (trying to invent expressions for numbers using genetic algorithm (the code itself is buggy in the Kill method, but I have trouble debugging it because python crashes). makeeq.py: #!/usr/bin/env python # Make equations using rpn and genetic algorithms from random import * from math import * import rpn def RanPosP(list): return int(uniform(0,len(list))+1) def RanPos(list): return int(uniform(0,len(list))) def AddUnary(list): a1=RanPosP(list) a2=RanPos(Unary) list=list[:a1]+[Unary[a2]]+list[a1:] return list def AddBinary(list): a1=RanPosP(list) a2=RanPos(Binary) num=int(uniform(0,10)) #print "Add binary:",list,num,rpn.Binary()[a2] list=list[:a1]+[num]+[Binary[a2]]+list[a1:] #print 'Add binary:',list return list class RPNGen: def __init__(self,target): self.pool=[[1]] self.rpn=[1.0] self.target=target def GetRPN(self): self.rpn=map(rpn.SolveRPN,self.pool) def Grow(self,N): for x in range(N): ihave=[] while rpn.SolveRPN(ihave)==None: ml=len(self.pool) #print self.pool ii=int(uniform(0,ml)) action=int(uniform(0,4)) #print action if action==0: ihave=(AddUnary(self.pool[ii])) elif action==1: ihave=(AddBinary(self.pool[ii])) elif action==2: jj=int(uniform(0,len(self.pool))) bit=self.pool[jj] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) if a2>a1: bit=bit[a1:a2] else: bit=bit[a2:a1] a3=int(uniform(0,len(self.pool[ii]))) ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:]) elif action==3: bit=self.pool[ii] a1=int(uniform(0,len(bit))) a2=int(uniform(0,len(bit))) ihave=(self.pool[ii][:a1]+self.pool[ii][a2:]) self.pool.append(ihave) self.rpn.append(rpn.SolveRPN(ihave)) #print self.pool,self.rpn deletelist=[] for cc in range(len(self.pool)): if self.rpn[cc]==None: deletelist.append(cc) while len(deletelist)>0: cc=deletelist.pop() self.rpn.pop(cc) self.pool.pop(cc) def Kill(self,N): TODO=N print "TODO:",TODO difs=map(lambda x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool) dict={} for x in range(N): dict[difs[x]]=x mn=min(dict.keys()) for x in range(N+1,len(difs)): print 'dict:',dict if difs[x]>mn: del dict[mn] dict[difs[x]]=x mn=min(dict.keys()) list=dict.values() list.sort() TODO-=len(list) for cc in range(len(list)): dd=list.pop() #print "asd", dd, self.rpn.pop(dd) self.pool.pop(dd) Test=RPNGen(137.03599976) Binary=rpn.Binary() Unary=rpn.Unary() for i in range(100): Test.Grow(100) #print len(Test.pool) for i in range(100): Test.Grow(100) Test.Kill(100) print len(Test.pool) for i in range(99): Test.Kill(200) Test.Grow(100) print len(Test.pool) for i in range(99): Test.Kill(1) print len(Test.pool),Test.rpn #print len(Test.pool),Test.pool, Test.rpn print Test.pool print Test.rpn ----------------------------------------------- rpn.py: #module for rpn from math import * def Unary(): return ['sin','cos','tan','asin','acos','atan','neg'] def Binary(): return ['+','-','*','/','^'] def SolveRPN(rpnl): stack=[] for each in rpnl: try: num=float(each) stack.append(num) except: try: #must be an operator then. if each=='+': stack.append(stack.pop()+stack.pop()) elif each=='-': a1=stack.pop() a2=stack.pop() stack.append(a2-a1) elif each=='*': stack.append(stack.pop()*stack.pop()) elif each=='/': a1=stack.pop() a2=stack.pop() stack.append(a2/a1) elif each=='^': a1=stack.pop() a2=stack.pop() stack.append(a2**a1) elif each=='cos': stack[-1]=cos(stack[-1]) elif each=='sin': stack[-1]=sin(stack[-1]) elif each=='tan': stack[-1]=tan(stack[-1]) elif each=='acos': stack[-1]=acos(stack[-1]) elif each=='asin': stack[-1]=asin(stack[-1]) elif each=='atan': stack[-1]=atan(stack[-1]) elif each=='neg': stack[-1]=-1.0*stack[-1] else: print "Unknown operation",each except: return None if len(stack)<>1: #print "Stack ended non-empty:",stack return None return stack[0] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-03-17 17:06 Message: Logged In: YES user_id=31435 Which operating system and C compiler? Since the assert() is checking the errno result from your platform libm's pow() function, the resolution of this is going to depend on which C library you're using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470 From noreply@sourceforge.net Mon Mar 17 22:14:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 14:14:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-702147 ] --without-cxx flag of configure isn't documented. Message-ID: Bugs item #702147, was opened at 2003-03-12 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 23:14 Message: Logged In: YES user_id=21627 Yes, please attached unified or context diffs to this bug report, preferably using the CVS version of Python (or 2.3a2 if CVS is not possible). ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 20:30 Message: Logged In: YES user_id=732192 It becomes clear for me that making a good help for all systems out there is very difficult. But I could create a better ./configure --help output for python that is comon for all systems. And I can create a patch for the README file that explains the libstdc++ dependencies if you are building with GNU C++. Can I simply add a patch for these to the patch list or how does it work? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 19:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 13:24 Message: Logged In: YES user_id=732192 For example.......... The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGS C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. ---------------------------------------------------------------------- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 12:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find the relation between the --with-cxx= flag and the libstdc++ library. The README file tells something about the --with-cxx flag. But not that this causes the libstdc++ inclusion (not everyone is C/C++ expert). Afther reading the README file it's also not logical why --with-cxx is choosen as default. Another problem a had: I'am missing the default settings with the --with/--wthout and --disable/--enable settings, or are all settings listed under "--enable and --with options recognized:" in the configure output defaults? Maybe this info should be added the same way as this line from the configure output. "Options: [defaults in brackets after descriptions]". I have these points for improvement: - Make clear in the README file, with the --with-cxx explenation that this causes libstdc++ inclusion. - Make clear in the configure output that all listed --with/--without/--enable/--disable flags are the default (mmm, this sounds logical for me now...). - Make clear in the configure output that all listed --with/--without/--enable/--disable flags have always a oposite. (this sounds also logical now, they're all bools....). - Why is --with-cxx choosen as default, the README file suggests that you only want this if.............. I'am not a ./configure or c++ expert, maybe my points are logical and normal behaviour for you. But I'am sure they will help other poeple that arn't expert either. And yes I can make a patch for these points. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-15 14:33 Message: Logged In: YES user_id=21627 This is a general configure principle: For every --with option, it is possible to pass --without, and for every --enable option, it is posible to pass --disable. Would you be willing to create a patch that explains this to the user in a way that you would understand? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 From noreply@sourceforge.net Mon Mar 17 23:05:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 15:05:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-705295 ] Error when using PyZipFile to create archive Message-ID: Bugs item #705295, was opened at 2003-03-17 15:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705295&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: Error when using PyZipFile to create archive Initial Comment: I get the following trace back while using the PyZipFile class to create zip import files. Traceback (most recent call last): File "../fsmGenerate.py", line 125, in ? main() File "../fsmGenerate.py", line 121, in main generate(inFileName, outName, app, gui, schema, zip) File "../fsmGenerate.py", line 56, in generate outZip.write(name) File "/usr/local/lib/python2.3/zipfile.py", line 427, in write self.fp.write(zinfo.FileHeader()) File "/usr/local/lib/python2.3/zipfile.py", line 167, in FileHeader fileHeader = '%s%s%s' % (header, self.filename, self.extra) UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 10: ordinal not in range(128) This error occurs intermitently. It seems to be related to the time. Looking in file Lib/zipfile.py, it appears that the call to struct.pack() in method ZipInfo.FileHeader() is creating a string containing bytes with values > 0x7F. I believe that these values are coming from local variable dostime in ZipInfo.FileHeader(). I'm using Python 2.3a2, built from source on Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705295&group_id=5470 From noreply@sourceforge.net Tue Mar 18 13:43:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 05:43:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-697556 ] test_posix fails: getlogin Message-ID: Bugs item #697556, was opened at 2003-03-04 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Neal Norwitz (nnorwitz) Summary: test_posix fails: getlogin Initial Comment: I see bug #690081 made this run only in interactive mode, but it still fails for me when I do a make test. Apparently my utmp is in an unexpected place, /var/run/, which I guess doesn't agree with my libc? I don't know how common this bug will be for other people, but if anyone else experiences it you should probably just get rid of the getlogin test altogether, or at least catch the OSError: (2, 'No such file or directory') and don't have that mean test failure. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 08:43 Message: Logged In: YES user_id=33168 Rather than implement the attached patch, I have removed the test for getlogin(). The test had minimal benefit (it only tested that getlogin() took no arguments). It failed several times for several different reasons. It could also fail under screen. See http://mail.python.org/pipermail/python-dev/2003-March/034120.html Checked in as Lib/test/test_posix.py 1.5 ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-06 23:05 Message: Logged In: YES user_id=670441 Yeah, this patched fixed it just fine. As long as I've got you here, should test_socket require the network resource be enabled? It only works for me when I'm connected. When not connected testHostnameRes fails because getfqdn() returns my hostname, 'zazz', but gethostbyaddr(ip) returns the hostname 'localhost'. When I am connected getfqdn() also returns 'localhost' so there's no problem. It could be fixed for me by either requiring the network resource or changing line 234 of test_socket from: all_host_names = [hname] + aliases to: all_host_names = [hname, hostname] + aliases Or maybe my machine's setup is just messed up in which case I trust you won't worry about it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 19:09 Message: Logged In: YES user_id=33168 Michael, can you test the attached patch? It should fix the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-06 01:26 Message: Logged In: YES user_id=33168 I'll take a look at this soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697556&group_id=5470 From noreply@sourceforge.net Tue Mar 18 18:17:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 10:17:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-688907 ] Applet support is broken Message-ID: Bugs item #688907, was opened at 2003-02-18 19:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=688907&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Applet support is broken Initial Comment: Applet support is broken in two ways: - there is no sys.argv emulation anymore, and applets always see the -psnXXXX argument when started from the finder. - when an applet is started from the commandline it is non-functional (no window manager connection). Also, the building of the Idle applet doesn't work due to name conflicts. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-03-18 19:17 Message: Logged In: YES user_id=92689 I think this issue is completely fixed in CVS: - the bootstrap script is written in Python again, using os.execve(), so the commandline vs. Finder issue is gone - sys.executable is correctly set in main.c by means of an environment variable passed by the bootstrap script. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-26 10:18 Message: Logged In: YES user_id=92689 #!: I misread you, what you suggest would work for applets to be run on the local system, but not for standalone apps: these need to be able to run on vanilla 10.2 installs. Although I'm not entirely comfortable with depending on /usr/bin/python, removing it (without replacing it with a different version) is an extremely bad idea, just like you're not supposed to remove /usr/bin/perl, as it would break the maintainance cron jobs (and probably much else). I would be happier to just use a shell script as before, but the entire point of this exercise was to fix the fact that we can't do something equivalent to os.execve() in sh (ie. lie about argv[0]). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-26 09:53 Message: Logged In: YES user_id=92689 #!: That's the worst idea ever, as you will not be able to move your app *at* *all*. Instead of using env, using /usr/bin/python should be ok. I just used env in the hope it would still work when someone removes /usr/bin/python and replaces it with a Python in a different location. Hm, this is brittle also, so I suggest to just hard-code /usr/bin/python. sitecustomize: hm, good point. Alternative: insert a hacked site.py (copy the original, add a couple of lines). I really want to get sys.executable right, as the client code is likely not aware (or rather *shouldn't* be aware) of whether it's run with argvemulator or not. This would/should result in *all* client code using the os.environ idiom. Eg. I don't expect the IDE to use the argvemulator, yet it will create applets, hence needs sys.executable. I feel strongly this is an either/or case: either we *always* set sys.executable or we don't do it ever. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 23:25 Message: Logged In: YES user_id=45365 Something that just struct me: by putting the full pathname to a known interpreter into the #! line we also regain 10.1 compatibility again! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 23:07 Message: Logged In: YES user_id=45365 Two remarks: - I really disagree with the sitecustomize.pyc. It obscures any real sitecustomize.py that the python admin may have installed, leading to weird behaviour (scripts will see the real sitecustomize but applets not). I think we should really handle this only in the argv emulator, which is going to be used for all "dumb" applets, and let "smart" applets handle it themselves by adding the two-liner if os.environ.has_key("PYTHONEXECUTABLE"): sys.executable = os.environ["PYTHONEXECUTABLE"] - I don't like the #!/usr/bin/env construct, why not use simply the same Python that Contents/MacOS/Python links to? If that Python goes away the applet will stop working anyway, so I see no reason to let the applet depend on possibly two different Pythons. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 21:12 Message: Logged In: YES user_id=92689 I've found a solution: site[customize].py, I have a patch ready: bundlebuilder.py adds a sitecustomize.pyc to the bundle which sets sys.executable according to the PYTHONEXECUTABLE environment variable. Standalone apps already have a custom site.py, so the sys.executable munging happens there. I'll just check it in I suppose... Leaving this item open until Jack confirms everything works as it should. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 16:43 Message: Logged In: YES user_id=92689 But we can only set it if there's a wrapper, and that's not always the case. Unless we add code to the Python _core_ that sets sys.executable if the environment variable is set. I doubt that would be accepted. Or would there at the C level be a different way to distinguish between argv[0] as set by execve() and the actual executable? Name: I would like to avoid accidental breakage, so longer is better... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 16:35 Message: Logged In: YES user_id=45365 Good idea, but I would suggest that we *do* set sys.executable. It may be used deep down in other modules. And as per Guido's dictum sys.executable is expected to point to a python interpreter. As to the name of the environment variable, why not simply PYTHON? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 16:21 Message: Logged In: YES user_id=92689 Here's a further idea: let the bootstrap script instead set an environment variable called PYTHONEXECUTABLE. The argv support code could use this to properly set sys.executable, and apps without the need for argv emulation (ie. any not-100% braindead GUI app) would also be able to get at the right value. Perhaps it's even better to _not_ set sys.executable in wrapper code, but change the client code to: if "PYTHONEXECUTABLE" in os.environ: executable = os.environ["PYTHONEXECUTABLE"] else: executable = sys.executable That way the client code is guaranteed to work correctly independent of whether the argv wrapper was used. Perhaps a less generic name should be chosen, eg. PYTHONBUNDLEEXECUTABLE. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-25 11:48 Message: Logged In: YES user_id=45365 Idea: we solve this for 50% and document it for 50%. The "solve" bit involves applets that have the sys.argv support. This code is generated anyway, so we generate one extra line that sets sys.executable. It can do so, because we know what we want to put in there (bundlebuilder has just created the symlink anyway). The document bit means that we have to state somewhere that if you create an applet without sys.argv emulation you are responsible yourself for setting it correctly. We do this in the IDE, so if we clearly flag the code that does this we've alreadly done quite a bit of "documenting". ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 09:54 Message: Logged In: YES user_id=92689 I have a fix ready, but as I wrote in private, this will cause sys.executable to be different (ie. it will be the same as CFBundleExecutable). This apparently breaks your stuff, as well as bundlebuilder itself if it is run from a bundle it created itself... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-24 17:40 Message: Logged In: YES user_id=45365 Building the Idle applet has been fixed (Mac/OSX/Makefile rev 1.36). So now the python-based applet main program is the only thing that needs to be done. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-19 00:48 Message: Logged In: YES user_id=45365 Just thinks he can fix the commandline problem with a Python script, so assigning to him. Will you please also update Misc/NEWS if you do? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-02-19 00:44 Message: Logged In: YES user_id=45365 sys.argv emulation works again, and that's the main part of this bug. A note has been added to NEWS that starting from the finder is broken in 2.3a2. Building of Idle I cannot test right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=688907&group_id=5470 From noreply@sourceforge.net Tue Mar 18 18:20:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 10:20:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-607814 ] IDE look and feel Message-ID: Bugs item #607814, was opened at 2002-09-11 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: IDE look and feel Initial Comment: The IDE needs to get a more MacOSX-like look and feel. I would suggest using the standard fonts for the various UI components (I know how attached you are to Python-Sans, so let's reformulate that as "optionally using the standard fonts"), and making all buttons, scrollbars and other such elements the standard sizes. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-03-18 19:20 Message: Logged In: YES user_id=92689 Jack, assigning to you, feel free to close it as "won't fix". What we really need is a new IDE, written with PyObjC. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-11 17:08 Message: Logged In: YES user_id=45365 What time frame are you thinking? We need something decent for Python 2.3, and I would think that a complete W rewrite may be too much work. Note that I'm perfectly willing to do a bit of tweaking myself, as long as it's ok with you. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-09-11 15:31 Message: Logged In: YES user_id=92689 All true, but there's SO much that's not 100% ok on OSX, that I'm considering abandoning the W gui kit altogether. As long as I'm not sure what the best way is (either a better gui kit based on Carbon or going all the way with Cocoa) I don't want to spend all that much time on W and IDE. So how's pyobjc coming along? ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607814&group_id=5470 From noreply@sourceforge.net Tue Mar 18 19:33:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 11:33:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-705792 ] test_atexit fails in directories with spaces Message-ID: Bugs item #705792, was opened at 2003-03-18 19:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: test_atexit fails in directories with spaces Initial Comment: The regression test program test_atexit.py constructs a command line without doing any quoting of arguments. If the name of the build directory contains spaces, the command doesn't work and the test fails. Here's what happens in Windows: H:\benh\My Documents\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. Traceback (most recent call last): File "test_atexit.py", line 33, in ? """) File "test_support.py", line 122, in vereq raise TestFailed, "%r == %r" % (a, b) test_support.TestFailed: '' == "handler2 (7,) {'kw': 'abc'}\nhandler2 () {}\nhandler1\n" [5168 refs] If I change the current directory to use a compatibility name without a space in it: H:\benh\My Documents\python\Python-2.2.2\Lib\test>cd h:\benh\mydocu~1\python\python-2.2.2\lib\test H:\benh\MYDOCU~1\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. [5168 refs] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 From noreply@sourceforge.net Tue Mar 18 20:17:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 12:17:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order Message-ID: Bugs item #705836, was opened at 2003-03-18 20:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Hill (richardh2003) Assigned to: Nobody/Anonymous (nobody) Summary: struct.pack of floats in non-native endian order Initial Comment: Python version 2.1 (2.2.1 behaves the same). Windows 2000 and RH Linux 8.0 This was run on an Intel platform. >>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 >>> v 7.9999999999999964 >>> struct.pack( "f", v ) '\x00\x00\x00A' >>> struct.pack( ">f", v ) '@\x80\x00\x00' These two should be the same byte pattern (only reversed)! >>> struct.unpack( ">f", '@\x80\x00\x00' ) (4.0,) !!!!! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470 From noreply@sourceforge.net Wed Mar 19 00:32:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 16:32:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-705983 ] simple HTMLParser doesn't ignore < within pre-formatted text Message-ID: Bugs item #705983, was opened at 2003-03-19 00:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705983&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David C. Fox (dcfox) Assigned to: Nobody/Anonymous (nobody) Summary: simple HTMLParser doesn't ignore < within pre-formatted text Initial Comment: The simple HTMLParser in the HTMLParser module fails to ignore angle brackets or less-than signs within preformatted text delimited by 
 ...
or examples ... . For example, if I use HTMLParser.HTMLParser to parse the contents of http://www.ataword.com/programming/dragons.html, I get the following (incorrect) error message: Traceback (most recent call last): File "", line 1, in ? p.close() File "E:\PYTHON22\lib\HTMLParser.py", line 112, in close self.goahead(1) File "E:\PYTHON22\lib\HTMLParser.py", line 166, in goahead self.error("EOF in middle of construct") File "E:\PYTHON22\lib\HTMLParser.py", line 115, in error raise HTMLParseError(message, self.getpos()) HTMLParseError: EOF in middle of construct, at line 50, column 31 The more advanced parser in htmllib deals with these cases properly. Even if this isn't worth fixing, it would be nice if this limitation were noted in the library documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705983&group_id=5470 From noreply@sourceforge.net Wed Mar 19 00:42:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 16:42:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-705792 ] test_atexit fails in directories with spaces Message-ID: Bugs item #705792, was opened at 2003-03-18 14:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 Category: None >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: test_atexit fails in directories with spaces Initial Comment: The regression test program test_atexit.py constructs a command line without doing any quoting of arguments. If the name of the build directory contains spaces, the command doesn't work and the test fails. Here's what happens in Windows: H:\benh\My Documents\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. Traceback (most recent call last): File "test_atexit.py", line 33, in ? """) File "test_support.py", line 122, in vereq raise TestFailed, "%r == %r" % (a, b) test_support.TestFailed: '' == "handler2 (7,) {'kw': 'abc'}\nhandler2 () {}\nhandler1\n" [5168 refs] If I change the current directory to use a compatibility name without a space in it: H:\benh\My Documents\python\Python-2.2.2\Lib\test>cd h:\benh\mydocu~1\python\python-2.2.2\lib\test H:\benh\MYDOCU~1\python\Python-2.2.2\Lib\test>..\..\pcbuild\python_d test_atexit.py Adding parser accelerators ... Done. [5168 refs] ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 19:42 Message: Logged In: YES user_id=33168 Directories with spaces should work with current CVS. The fix needs to be backported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705792&group_id=5470 From noreply@sourceforge.net Wed Mar 19 00:44:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 16:44:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads? Message-ID: Bugs item #704641, was opened at 2003-03-16 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) >Assigned to: Jason Tishler (jlt63) Summary: _tkinter.c won't build w/o threads? Initial Comment: I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but... Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin. For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined. And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop(). And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 19:44 Message: Logged In: YES user_id=33168 Jason, can you help with this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 From noreply@sourceforge.net Wed Mar 19 00:48:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 16:48:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-704919 ] Problems building python with tkinter on HPUX... Message-ID: Bugs item #704919, was opened at 2003-03-17 06:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayce Piel (jayce) Assigned to: Nobody/Anonymous (nobody) Summary: Problems building python with tkinter on HPUX... Initial Comment: I have some problems when trying to install python on a HPUX 10.20 system. All seems to go well during the compiling and during the installation process, but when I try to use tkinter in my new python with an "import _tkinter", i have the following lines : Python 2.2.2 (#2, Mar 17 2003, 04:36:02) [GCC 2.95.2 19991024 (release)] on hp-ux10 Type "help", "copyright", "credits" or "license" for more information. >>> import _tkinter /usr/lib/dld.sl: Unresolved symbol: acos (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: asin (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: atan (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: cosh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: log10 (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: sinh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: tan (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved symbol: tanh (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclTraceExec (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclProcBodyType (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclFreeObjList (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: tclExecutableName (data) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl /usr/lib/dld.sl: Unresolved module for symbol: Tcl_FindExecutable (code) from /usr/local/lib/python2.2/lib-dynload/_tkinter.sl zsh: abort (core dumped) python I have a python1.5/tkinter that works with tcl/tk 8.0p2... When trying to compile with this version of tcl/tk, i had errors with the tkinter module compilation. Then, I tried to compile a tcl/tk 8.4.2, or even use a binary-package of a tcl/tk 8.2.1, but in both cases I have the above errors when running... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 19:48 Message: Logged In: YES user_id=33168 The problem appears to be that -lm (ie the math library) needs to be linked, but is not. I do not have access to a 10.20 machine. It also looks like the tcl library may not be found. Perhaps there's a library search problem? Jayce, if you could produce a patch that works for you, I can check in a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470 From noreply@sourceforge.net Wed Mar 19 00:50:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 16:50:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 12:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Gustavo Niemeyer (niemeyer) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-19 00:50 Message: Logged In: YES user_id=7887 Commited as: Include/pystate.h: 2.23 Misc/NEWS: 1.699 Python/codecs.c: 2.21 Python/pystate.c: 2.24 Python/pythonrun.c: 2.182 Thanks for your support! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-07 17:36 Message: Logged In: YES user_id=38388 Oh, I see what you mean. In that case, it's OK to add them just before the optional parts. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-07 17:20 Message: Logged In: YES user_id=7887 No problems. If you don't mind, I'd just to have a confirmation: are you sure I should move the new fields to the end, and leave a conditional member in the middle? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-04 10:07 Message: Logged In: YES user_id=38388 Same comments as Guido, plus: * in the interpreter state struct you should add the new fields to the end, not in the middle * the finalization phase is moved to a later point in the process; this could cause problems when finalizing codecs -- I guess we'll just have to see whether we get bug reports related to this; perhaps it's better to ZAP the dicts before ZAPping builtins etc. ?! Great work, Gustavo. Please check the patch in with the above changes. Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-01 14:41 Message: Logged In: YES user_id=6380 I can't review this beyond "it doesn't break the tests for me"; I suggest to assign to MAL for review. One note: I got a compiler warning implicit declaration of function `_PyCodecRegistry_Init' to fix, add static int _PyCodecRegistry_Init(void); /* Forward */ somewhere to the top of codecs.c. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-03-01 08:07 Message: Logged In: YES user_id=7887 Here is a proposed solution. It has been tested with the standard regression tests, and in an environment with multiple interpreters. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-02-12 13:13 Message: Logged In: YES user_id=7887 As discussed in python-dev, I'll work on that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 12:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 10:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 12:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Wed Mar 19 00:55:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 16:55:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-704194 ] Problems printing and sleep Message-ID: Bugs item #704194, was opened at 2003-03-15 12:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704194&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: ross (zepplin) Assigned to: Nobody/Anonymous (nobody) Summary: Problems printing and sleep Initial Comment: When I do the following: gui = input("Whats your name?") print gui Sleep(1000) I can input my name, but the program then closes. Are there any includes or return 0's like in C++? Could the above code be my entire program? It seems like I need to start or end the program somehow... Well thanks, sorry if the answer to this is already here. I didn't see anything like it. And where are the forums? Thanks again. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 19:55 Message: Logged In: YES user_id=33168 This doesn't appear to be a bug, but that you don't understand how python works. Is that correct? If so, there are several places to ask for help, including the comp.lang.python newsgroup, python-help@python.org or tutor@python.org. You may also want to visit http://python.org/doc/Newbies.html You can "include" other modules with the import statement. There is a return statement similar to C. The code above can be your entire program in python. If this is truly a bug, I'm sorry I misunderstood. Please close this bug report if it's not a bug though. Thanks, and welcome to Python! :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704194&group_id=5470 From noreply@sourceforge.net Wed Mar 19 01:06:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 17:06:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug Message-ID: Bugs item #702775, was opened at 2003-03-13 01:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Nobody/Anonymous (nobody) Summary: dumbdbm __del__ bug Initial Comment: I used shelve.py and it falls back on dumbdbm when no possible alternatives are found on the system. I found this error, which is recurrent and deterministic: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error'" in > ignored The problem seems to reside in the __del__ of dumbdbm._Database: class _Database: ... def __del__(self): if self._index is not None: self._commit() ... def _commit(self): try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() My investigation showed that the error was from _commit. When it was called, _os or _open was both None. And the exception catch didn't work quite safely cause its in the "except" clause. The reason I suspect is when the time that _Database.__del__ was called the os module(which is imported as _os) is already removed out. I changed the code as: def _commit(self): global _os if _os is None: import os as _os import __builtin__ _open = __builtin__.open try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass ...... Now it works without any problems, AFAIK. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 20:06 Message: Logged In: YES user_id=33168 Can you provide a test case which triggers this problem? I can't see how _os becomes None. Also I would like to add a test. Thanks. ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2003-03-13 12:02 Message: Logged In: YES user_id=116941 see the thread at http://groups.google.com/groups? selm=ba1e306f.0303111337.72a696c7% 40posting.google.com , esp. by my name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 From noreply@sourceforge.net Wed Mar 19 01:10:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 17:10:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-699379 ] ncurses/curses on solaris Message-ID: Bugs item #699379, was opened at 2003-03-07 08:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699379&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Iain Morrison (iainmorrison) Assigned to: Nobody/Anonymous (nobody) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 20:10 Message: Logged In: YES user_id=33168 Closing this bug since it appears to be an exact duplicate of 700780 which already has comments. Iain, can you provide any more info to the questions asked in the other bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699379&group_id=5470 From noreply@sourceforge.net Wed Mar 19 01:24:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 17:24:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Neal Norwitz (nnorwitz) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 20:24 Message: Logged In: YES user_id=33168 I tried the test code which prints the type of borderwidth from a frame. In both 2.3 and 2.2.2 I get a string. I'm running with tk 8.3 on Linux. What OS are you running? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-12 13:12 Message: Logged In: YES user_id=80475 Neal,I saw that you've been maintaining _tkinter.c. Do you have time to look into the behavior change for widget.cget ()? It would be great if PmW could be kept working under Py2.3. Corvus, thanks for the precise bug report. I think it gets to the heart of the matter. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-12 11:14 Message: Logged In: YES user_id=2138 I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2). In Python 2.3, widget.cget() will return ints in stead of strings where it needs to. My test code: import Tkinter a = Tkinter.Frame()['borderwidth'] print type(a), a Pmw assumes the return values of all cget calls will be strings. If there's a bug here, it's just that Pmw doesn't yet support Python 2.3. I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 17:39 Message: Logged In: YES user_id=80475 Corvus, did you have any luck finding the offending lines in PmW? Can this bug be posted on PmW's SF site and closed here or do you guys think something still needs to be fixed in Python? ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 16:57 Message: Logged In: YES user_id=454042 We don't see the problem in Python 2.1. In fact initially we fell back to 2.1 but I don't want to stay there. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 15:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 19 02:57:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 18:57:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError Message-ID: Bugs item #697591, was opened at 2003-03-04 17:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Murff (jmurff) Assigned to: Neal Norwitz (nnorwitz) Summary: string.atoi function causing TypeError Initial Comment: Discoved this when using Pmw with 2.3a1 and a2 found atoi doesn't work properly. So, I wrote a small test: ------------------ import string if __name__ == __main__: num = atoi(test, 10) ------------------ Always get and exception from it and using Pmw that is the same: <...> python2.3/string.py, line 220 return _int(s, base) TypeError: int() can't convert non-string with explicit base Seems to always pass a string like it asks for. I can also reproduce by using the MenuBar.py and MainMenuBar.py in Pmw/Pmw1.1/demos. I fixed it by looking at python2.3/stringold.py. I took the guts of atoi from there. So it was: --------------- def atoi(s, base=10) : return _int(s, base) It is now: -------------- def atoi(*args) : try: s = arg[0] except IndexError: raise TypeError('function requires a least one argument: %d given' % len(args)) return apply(_int, args) Hope this helps. Not sure if it is best way to fix it but solved all our errors using atoi for now. Let me know if you need more info. - jmurff@pacbell.net ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-18 21:57 Message: Logged In: YES user_id=2138 I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 20:24 Message: Logged In: YES user_id=33168 I tried the test code which prints the type of borderwidth from a frame. In both 2.3 and 2.2.2 I get a string. I'm running with tk 8.3 on Linux. What OS are you running? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-12 13:12 Message: Logged In: YES user_id=80475 Neal,I saw that you've been maintaining _tkinter.c. Do you have time to look into the behavior change for widget.cget ()? It would be great if PmW could be kept working under Py2.3. Corvus, thanks for the precise bug report. I think it gets to the heart of the matter. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-12 11:14 Message: Logged In: YES user_id=2138 I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2). In Python 2.3, widget.cget() will return ints in stead of strings where it needs to. My test code: import Tkinter a = Tkinter.Frame()['borderwidth'] print type(a), a Pmw assumes the return values of all cget calls will be strings. If there's a bug here, it's just that Pmw doesn't yet support Python 2.3. I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-11 17:39 Message: Logged In: YES user_id=80475 Corvus, did you have any luck finding the offending lines in PmW? Can this bug be posted on PmW's SF site and closed here or do you guys think something still needs to be fixed in Python? ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 16:57 Message: Logged In: YES user_id=454042 We don't see the problem in Python 2.1. In fact initially we fell back to 2.1 but I don't want to stay there. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-05 15:43 Message: Logged In: YES user_id=2138 Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this: 0 0 I'll try digging in Pmw to see if I can find the error. I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-05 14:40 Message: Logged In: YES user_id=80475 Values like 'str' are being properly flagged as invalid literals. We need to find out the value and type that is causing the error in Pmw. Can you insert a "print >> sys.stderr, type(s), repr(s), str(s)" at the beginning of the atoi() code. The lines in the string.atoi() code have been around since Py1.6, so if this is a new error, then it means that the behavior of int(s, 10) has changed in subtle ways or that the object s has changed in some way. I would like to fix only the thing that caused the error and avoid altering the string.atoi code which has been around for so long. The easiest way to track this one down is to simplify the bug report to something like this: string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 when s is UserString with the value of " 10". BTW, a simpler workaround is to change string.atoi to: def atoi(s, *args) : return _int(s, *args) ---------------------------------------------------------------------- Comment By: Jim Murff (jmurff) Date: 2003-03-05 13:49 Message: Logged In: YES user_id=454042 I tried all kinds of values for the test variable... 'str' "str" sys.argv[0]. They all complained about invalid literal. Pmw code showed other error. These used 'str' or a return from a method as i recall. Yes i meant "string.atoi" -- sorry :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-04 21:18 Message: Logged In: YES user_id=80475 I'll take a look at this one. Can you provide the value and type of the "test" variable when the exception was raised? Also, please confirm that the test code meant to say: "num = string.atoi(test, 10) ". ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2003-03-04 20:50 Message: Logged In: YES user_id=2138 I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470 From noreply@sourceforge.net Wed Mar 19 03:09:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 19:09:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads? Message-ID: Bugs item #704641, was opened at 2003-03-16 11:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Jason Tishler (jlt63) Summary: _tkinter.c won't build w/o threads? Initial Comment: I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but... Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin. For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined. And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop(). And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-03-18 18:09 Message: Logged In: YES user_id=86216 nnorwitz> Jason, can you help with this? Yes. The short answer is I have been meaning to update the official Python README. I guess that I can't procrastinate anymore... corvus> I'm out of my area of expertice here trying corvus> to build python on Windows using cygwin corvus> and trying to use Tcl/Tk 8.4.2, but... Do you really need to build CVS? Or, will the pre-built Cygwin Python 2.2.2 suffice? corvus> Anyway, it looks like I can't compile _tkinter.c corvus> unless I've configured python to use threads corvus> and I didn't because the main python README corvus> says not to with cygwin. Well, that's simple the "main python README" is wrong. See above. :,) If _tkinter requires threads under other Unixes, then I think that updating the official Python README is sufficient. Do others agree? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 15:44 Message: Logged In: YES user_id=33168 Jason, can you help with this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 From noreply@sourceforge.net Wed Mar 19 03:29:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 19:29:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads? Message-ID: Bugs item #704641, was opened at 2003-03-16 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Jason Tishler (jlt63) Summary: _tkinter.c won't build w/o threads? Initial Comment: I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but... Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin. For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined. And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop(). And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block. ---------------------------------------------------------------------- >Comment By: John Speno (corvus) Date: 2003-03-18 22:29 Message: Logged In: YES user_id=2138 jlt63> Do you really need to build CVS? Or, will the pre-built jlt63> Cygwin Python 2.2.2 suffice? At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now. Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-) Take care. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-03-18 22:09 Message: Logged In: YES user_id=86216 nnorwitz> Jason, can you help with this? Yes. The short answer is I have been meaning to update the official Python README. I guess that I can't procrastinate anymore... corvus> I'm out of my area of expertice here trying corvus> to build python on Windows using cygwin corvus> and trying to use Tcl/Tk 8.4.2, but... Do you really need to build CVS? Or, will the pre-built Cygwin Python 2.2.2 suffice? corvus> Anyway, it looks like I can't compile _tkinter.c corvus> unless I've configured python to use threads corvus> and I didn't because the main python README corvus> says not to with cygwin. Well, that's simple the "main python README" is wrong. See above. :,) If _tkinter requires threads under other Unixes, then I think that updating the official Python README is sufficient. Do others agree? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 19:44 Message: Logged In: YES user_id=33168 Jason, can you help with this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470 From noreply@sourceforge.net Wed Mar 19 06:09:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 18 Mar 2003 22:09:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-705983 ] simple HTMLParser doesn't ignore < within pre-formatted text Message-ID: Bugs item #705983, was opened at 2003-03-19 00:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705983&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David C. Fox (dcfox) Assigned to: Nobody/Anonymous (nobody) Summary: simple HTMLParser doesn't ignore < within pre-formatted text Initial Comment: The simple HTMLParser in the HTMLParser module fails to ignore angle brackets or less-than signs within preformatted text delimited by 
 ...
or examples ... . For example, if I use HTMLParser.HTMLParser to parse the contents of http://www.ataword.com/programming/dragons.html, I get the following (incorrect) error message: Traceback (most recent call last): File "", line 1, in ? p.close() File "E:\PYTHON22\lib\HTMLParser.py", line 112, in close self.goahead(1) File "E:\PYTHON22\lib\HTMLParser.py", line 166, in goahead self.error("EOF in middle of construct") File "E:\PYTHON22\lib\HTMLParser.py", line 115, in error raise HTMLParseError(message, self.getpos()) HTMLParseError: EOF in middle of construct, at line 50, column 31 The more advanced parser in htmllib deals with these cases properly. Even if this isn't worth fixing, it would be nice if this limitation were noted in the library documentation. ---------------------------------------------------------------------- >Comment By: David C. Fox (dcfox) Date: 2003-03-19 06:09 Message: Logged In: YES user_id=23703 Sorry, this isn't actually a bug. I was misinterpreting the meaning of the 
 tag.  All the browsers I've seen don't
mind unescaped < signs within PRE, but NCSA Beginner's Guide
to HTML says you still have to use <.  I should have
double checked the HTML standards first.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705983&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 06:10:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 18 Mar 2003 22:10:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-705983 ] simple HTMLParser doesn't ignore < within pre-formatted text
Message-ID: 

Bugs item #705983, was opened at 2003-03-19 00:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705983&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: David C. Fox (dcfox)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple HTMLParser doesn't ignore < within pre-formatted text

Initial Comment:
The simple HTMLParser in the HTMLParser module fails to
ignore angle brackets or less-than signs within
preformatted text delimited by 
 ... 
 or
examples  ... .

For example, if I use HTMLParser.HTMLParser to parse
the contents of

http://www.ataword.com/programming/dragons.html,

I get the following (incorrect) error message:

Traceback (most recent call last):
  File "", line 1, in ?
    p.close()
  File "E:\PYTHON22\lib\HTMLParser.py", line 112, in close
    self.goahead(1)
  File "E:\PYTHON22\lib\HTMLParser.py", line 166, in
goahead
    self.error("EOF in middle of construct")
  File "E:\PYTHON22\lib\HTMLParser.py", line 115, in error
    raise HTMLParseError(message, self.getpos())
HTMLParseError: EOF in middle of construct, at line 50,
column 31


The more advanced parser in htmllib deals with these
cases properly.

Even if this isn't worth fixing, it would be nice if
this limitation were noted in the library documentation.



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

Comment By: David C. Fox (dcfox)
Date: 2003-03-19 06:09

Message:
Logged In: YES 
user_id=23703

Sorry, this isn't actually a bug.  I was misinterpreting the
meaning of the 
 tag.  All the browsers I've seen don't
mind unescaped < signs within PRE, but NCSA Beginner's Guide
to HTML says you still have to use <.  I should have
double checked the HTML standards first.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705983&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 12:44:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 04:44:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-706253 ] python accepts illegal "import mod.sub as name" syntax
Message-ID: 

Bugs item #706253, was opened at 2003-03-19 13:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: python accepts illegal "import mod.sub as name" syntax

Initial Comment:
http://python.org/doc/current/ref/import.html
"To avoid confusion, you cannot import modules with
dotted names as a different local name. So import
module as m is legal, but import module.submod as s is
not."

sadly the interpreter accepts the illegal form without
comment which makes it "semi-legal".
packages that rely on this illegal form may cause
trouble with costum import implementations (i.e.
importing from zip file or similar)

tested with 2.2.2 and 2.3a2

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 13:05:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 05:05:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-19 14:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Tim Peters (tim_one)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 17:18:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 09:18:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-19 08:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
>Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-19 12:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 17:51:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 09:51:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-685846 ] raw_input defers alarm signal
Message-ID: 

Bugs item #685846, was opened at 2003-02-13 10:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685846&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input defers alarm signal

Initial Comment:
import signal
def handle(a,b):
   print "received signal"
signal.signal(signal.SIGALRM, handle)
signal.alarm(5)
name = raw_input('Please enter your name within 5
seconds: ')


waits for input forever instead of getting the signal
thrown
after 5 seconds.  If you wait more than 5 seconds before
typing your name, the signal does get handled after you
finally enter your input.

The workaround of calling sys.stdin.readline() instead of
raw_input does the right thing, so something is funny about
the raw_input function.


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

Comment By: Michael Stone (mbrierst)
Date: 2003-03-19 17:51

Message:
Logged In: YES 
user_id=670441

This isn't just a readline problem,
it's consistent whether or not readline
is used.  Patch #706406 attempts
to fix this problem in a reasonable manner,
but it may not be possible to fix perfectly.
Signals always seem pretty hopeless to
get really right, and python hardly tries
most of the time.  (Only handling them in
the main thread...)

I think raw_input really doesn't WANT to
just give up when receiving a signal, so the
patch has it give up only when the signal
handler throws an exception.

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

Comment By: Michael Hudson (mwh)
Date: 2003-02-13 11:46

Message:
Logged In: YES 
user_id=6656

I'm 99% sure this is readline's fault.

You might be able to test this by hiding the readline.so
from the interpreter.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685846&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 17:14:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 09:14:44 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: 

Feature Requests item #706392, was opened at 2003-03-19 11:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 19:01:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 11:01:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order
Message-ID: 

Bugs item #705836, was opened at 2003-03-18 15:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Hill (richardh2003)
>Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order

Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0

This was run on an Intel platform.

>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 
+ .1
>>> v
7.9999999999999964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'

These two should be the same byte pattern (only 
reversed)!

>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)

!!!!!



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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-19 14:01

Message:
Logged In: YES 
user_id=31435

Yuck.  It's a bug in not accounting for that rounding can 
spill over the original bit width.  structmodule's pack_float() 
and pack_double() both have this flaw, although the one in 
pack_double() is much subtler.  A similar cut-and-paste 
bug is in cPicke's save_float().  I'll fix all this.

Note:  while "f"'s, there's no defined relationship between either of 
those and plain "f".  "f" is platform-native in all respects.  "f" force an IEEE-like encoding, even on non-IEEE 
platforms.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 19:12:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 11:12:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-706450 ] test_socket fails when not connected
Message-ID: 

Bugs item #706450, was opened at 2003-03-19 19:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706450&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Stone (mbrierst)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_socket fails when not connected

Initial Comment:

Should test_socket require the network resource
be enabled?  It only works for me when I'm
connected (Running an old slackware linux).
This is true of both CVS and 2.2 python

When not connected testHostnameRes fails because
getfqdn() returns my hostname, 'zazz', but
gethostbyaddr(ip) returns the hostname 'localhost'.
When I am connected getfqdn() also returns
'localhost' so there's no problem.  It could be
fixed for me by either requiring the network
resource or changing line 234 of test_socket from:
all_host_names = [hname] + aliases
to:
all_host_names = [hname, hostname] + aliases

Or maybe my machine's setup is just messed
up in which case I trust you'll close the bug.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706450&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 21:35:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 13:35:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-706546 ] u''.translate not documented
Message-ID: 

Bugs item #706546, was opened at 2003-03-19 16:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
Assigned to: Nobody/Anonymous (nobody)
Summary: u''.translate not documented

Initial Comment:
The behaviour of u''.translate is significantly
different from ''.translate, yet the difference is not
reflected in the documentation.

- ''.translate takes one or two arguments, one a table
of 256 characters for the translation target and the
other a string containing characters to be removed.

- u''.translate only takes on argument, which is a
mapping from unicode ordinal to unicode ordinal,
ustring or None.

See also print u''.translate.__doc__

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 22:49:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 14:49:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-706585 ] Expose FinderInfo in FSCatalogInfo
Message-ID: 

Bugs item #706585, was opened at 2003-03-19 23:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706585&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Expose FinderInfo in FSCatalogInfo

Initial Comment:
Carbon.File.FSCatalogInfo should expose the finder info (which is somehow defined as an anonymous short array in the header) as the
correct Python object.

Here's a comment by Mark Day:
Yup, use the finderInfo.  It's really either FileInfo or FolderInfo (both from Finder.h), depending on whether the object is a file or folder.  Similarly, extFinderInfo is really either ExtendedFileInfo or ExtendedFolderInfo.  I think there was some circular header dependency that prevented Files.h from using the Finder types explicitly.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706585&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 22:55:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 14:55:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-706592 ] Crbon.File.FSSpec should accept non-existing pathnames
Message-ID: 

Bugs item #706592, was opened at 2003-03-19 23:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Crbon.File.FSSpec should accept non-existing pathnames

Initial Comment:
Carbon.File.FSSpec currently doesn't accept non-existing pathnames.
This can be fixed in a way similar to what EasyDialogs.AskFileForSave uses, I think.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 23:02:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 15:02:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-706595 ] codecs.open and iterators
Message-ID: 

Bugs item #706595, was opened at 2003-03-19 16:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Todd Reed (toddreed)
Assigned to: Nobody/Anonymous (nobody)
Summary: codecs.open and iterators

Initial Comment:
Greg Aumann originally posted this problem in 
comp.lang.python on Nov 4, 2002, but I could not find a 
bug report.  I've simply copied his news post, which 
explains the problem:
-----------
Recently I figured out how to use iterators and 
generators. Quite easy to
use and a great improvement.

But when I refactored some of my code I came across a 
discrepancy that seems
like it must be a bug. 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 the line is 
returned in non
unicode strings. Surely 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.

Is this definitely a bug, or is it an undocumented 'feature' 
of the codecs
module?

Greg Aumann

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=706595&group_id=5470


From noreply@sourceforge.net  Wed Mar 19 23:51:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 15:51:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-20 00:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

>Comment By: Mark Hammond (mhammond)
Date: 2003-03-20 10:51

Message:
Logged In: YES 
user_id=14198

I struck this years ago, but was in a quandry.  On one hand,
sys.stdout *is* invalid, and I see no reason why Python
should mask these errors.  There may be real applications
where this failure *must* be reported to the program rather
than simply consumed.

However, I see the point that print is so basic that is
should never fail.  To my mind, the first point outweighs
the first, and the problem is fairly simply solved (see if
sys.stdout is invalid, and if so, open a file and set it to
that).

So I am afraid that, no, I don't give a rats .  Unless
conivenced otherwise (ie, by Tim or Guido) I will close this
as "not a bug" in a week or so.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 04:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 04:17:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 20:17:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-19 08:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-19 23:17

Message:
Logged In: YES 
user_id=31435

I can swing either way on this, or even a third:  open text 
files stdout.txt and stderr.txt in the current directory then.  
That's really aiming at a different irritation, though, that 
tracebacks end up in the bit bucket by default under 
pythonw.

BTW, making stdout and stderr /dev/null workalikes is 
least attractive to me (nobody would write to stdout or 
stderr *intending* the output be lost).  I'm (barely) OK with 
letting it stay as it is, because that just reflects Windows 
reality.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-03-19 18:51

Message:
Logged In: YES 
user_id=14198

I struck this years ago, but was in a quandry.  On one hand,
sys.stdout *is* invalid, and I see no reason why Python
should mask these errors.  There may be real applications
where this failure *must* be reported to the program rather
than simply consumed.

However, I see the point that print is so basic that is
should never fail.  To my mind, the first point outweighs
the first, and the problem is fairly simply solved (see if
sys.stdout is invalid, and if so, open a file and set it to
that).

So I am afraid that, no, I don't give a rats .  Unless
conivenced otherwise (ie, by Tim or Guido) I will close this
as "not a bug" in a week or so.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 12:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 05:26:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 19 Mar 2003 21:26:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order
Message-ID: 

Bugs item #705836, was opened at 2003-03-18 15:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Richard Hill (richardh2003)
Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order

Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0

This was run on an Intel platform.

>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 
+ .1
>>> v
7.9999999999999964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'

These two should be the same byte pattern (only 
reversed)!

>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)

!!!!!



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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-20 00:25

Message:
Logged In: YES 
user_id=31435

Boosted priority because this is an especially bad kind of 
bug:  mysterious, subtle, and very rare ("most" in-range 
floats pack under "f" without problems; a problem 
requires that a carry out of the 25th most-significant-bit 
propagate thru a solid string of 24 1 bits).

For 2.2 I expect to check in a quick hack.  In 2.3 this code 
needs refactoring (structmodule and cPickle shouldn't have 
duplicated this delicate code)

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 14:01

Message:
Logged In: YES 
user_id=31435

Yuck.  It's a bug in not accounting for that rounding can 
spill over the original bit width.  structmodule's pack_float() 
and pack_double() both have this flaw, although the one in 
pack_double() is much subtler.  A similar cut-and-paste 
bug is in cPicke's save_float().  I'll fix all this.

Note:  while "f"'s, there's no defined relationship between either of 
those and plain "f".  "f" is platform-native in all respects.  "f" force an IEEE-like encoding, even on non-IEEE 
platforms.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 09:15:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 01:15:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-706546 ] u''.translate not documented
Message-ID: 

Bugs item #706546, was opened at 2003-03-19 22:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
Assigned to: Nobody/Anonymous (nobody)
Summary: u''.translate not documented

Initial Comment:
The behaviour of u''.translate is significantly
different from ''.translate, yet the difference is not
reflected in the documentation.

- ''.translate takes one or two arguments, one a table
of 256 characters for the translation target and the
other a string containing characters to be removed.

- u''.translate only takes on argument, which is a
mapping from unicode ordinal to unicode ordinal,
ustring or None.

See also print u''.translate.__doc__

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-03-20 10:15

Message:
Logged In: YES 
user_id=38388

Isn't the documentation clear enough about the difference ?

Note that u.translate() is not really all that useful. You
are much
better off with writing your own charmap based codec which
is not really difficult: just take a look at e.g. cp1251.py.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 09:19:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 01:19:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-19 14:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

>Comment By: Alexander Miseler (amiseler)
Date: 2003-03-20 10:19

Message:
Logged In: YES 
user_id=693638

then please throw a meaningful exception at first byte
written, not an obscure exception after 4096 bytes written.


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 05:17

Message:
Logged In: YES 
user_id=31435

I can swing either way on this, or even a third:  open text 
files stdout.txt and stderr.txt in the current directory then.  
That's really aiming at a different irritation, though, that 
tracebacks end up in the bit bucket by default under 
pythonw.

BTW, making stdout and stderr /dev/null workalikes is 
least attractive to me (nobody would write to stdout or 
stderr *intending* the output be lost).  I'm (barely) OK with 
letting it stay as it is, because that just reflects Windows 
reality.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-03-20 00:51

Message:
Logged In: YES 
user_id=14198

I struck this years ago, but was in a quandry.  On one hand,
sys.stdout *is* invalid, and I see no reason why Python
should mask these errors.  There may be real applications
where this failure *must* be reported to the program rather
than simply consumed.

However, I see the point that print is so basic that is
should never fail.  To my mind, the first point outweighs
the first, and the problem is fairly simply solved (see if
sys.stdout is invalid, and if so, open a file and set it to
that).

So I am afraid that, no, I don't give a rats .  Unless
conivenced otherwise (ie, by Tim or Guido) I will close this
as "not a bug" in a week or so.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 18:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 09:35:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 01:35:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-706595 ] codecs.open and iterators
Message-ID: 

Bugs item #706595, was opened at 2003-03-20 00:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Todd Reed (toddreed)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open and iterators

Initial Comment:
Greg Aumann originally posted this problem in 
comp.lang.python on Nov 4, 2002, but I could not find a 
bug report.  I've simply copied his news post, which 
explains the problem:
-----------
Recently I figured out how to use iterators and 
generators. Quite easy to
use and a great improvement.

But when I refactored some of my code I came across a 
discrepancy that seems
like it must be a bug. 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 the line is 
returned in non
unicode strings. Surely 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.

Is this definitely a bug, or is it an undocumented 'feature' 
of the codecs
module?

Greg Aumann

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: 2003-03-20 10:35

Message:
Logged In: YES 
user_id=38388

That's a bug in the iterator support which was added
to the codecs module: the .next() methods should not
call the .next() methods on the reader directly, but instead
redirect to the .readline() method.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706595&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 11:14:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 03:14:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion  failed, python aborts
Message-ID: 

Bugs item #705231, was opened at 2003-03-17 21:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Anze Slosar (anze)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion  failed, python aborts

Initial Comment:
This bug is reproducible with python 2.2.1 althogh it
fails only occasionally as the flow depends on random
numbers. 
It aborts by saying:

python: Objects/floatobject.c:582: float_pow: Assertion
`(*__errno_location ()) == 34' failed.
Aborted

I tried python 2.2.2 but as I try to install rpms I run
into every growing list of dependencies. I couldn't
reproduce the exact cause of the bug, but it is caused
by the following simple code (trying to invent
expressions for numbers using genetic algorithm (the
code itself is buggy in the Kill method, but I have
trouble debugging it because python crashes).

makeeq.py:

#!/usr/bin/env python
# Make equations using rpn and genetic algorithms

from random import *
from math import *
import rpn


def RanPosP(list):
    return int(uniform(0,len(list))+1)

def RanPos(list):
    return int(uniform(0,len(list)))

def AddUnary(list):
    a1=RanPosP(list)
    a2=RanPos(Unary)
    list=list[:a1]+[Unary[a2]]+list[a1:]
    return list

def AddBinary(list):
    a1=RanPosP(list)
    a2=RanPos(Binary)
    num=int(uniform(0,10))
    #print "Add binary:",list,num,rpn.Binary()[a2]
    list=list[:a1]+[num]+[Binary[a2]]+list[a1:]
    #print 'Add binary:',list
    return list

        
class RPNGen:
    def __init__(self,target):
        self.pool=[[1]]
        self.rpn=[1.0]
        self.target=target

    def GetRPN(self):
        self.rpn=map(rpn.SolveRPN,self.pool)
    
    def Grow(self,N):
        for x in range(N):
            ihave=[]
            while rpn.SolveRPN(ihave)==None:
                ml=len(self.pool)
                #print self.pool
                ii=int(uniform(0,ml))
                action=int(uniform(0,4))
                #print action
                if action==0:
                   ihave=(AddUnary(self.pool[ii]))

                elif action==1:
                    ihave=(AddBinary(self.pool[ii]))

                elif action==2:
                    jj=int(uniform(0,len(self.pool)))
                    bit=self.pool[jj]
                    a1=int(uniform(0,len(bit)))
                    a2=int(uniform(0,len(bit)))
                    if a2>a1:
                        bit=bit[a1:a2]
                    else:
                        bit=bit[a2:a1]
                    a3=int(uniform(0,len(self.pool[ii])))
                   
ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:])

                elif action==3:
                    bit=self.pool[ii]
                    a1=int(uniform(0,len(bit)))
                    a2=int(uniform(0,len(bit)))
                   
ihave=(self.pool[ii][:a1]+self.pool[ii][a2:])
            self.pool.append(ihave)
            self.rpn.append(rpn.SolveRPN(ihave))
                
        #print self.pool,self.rpn
        deletelist=[]
        for cc in range(len(self.pool)):
            if self.rpn[cc]==None:
                deletelist.append(cc)

        while len(deletelist)>0:
            cc=deletelist.pop()
            self.rpn.pop(cc)
            self.pool.pop(cc)

    def Kill(self,N):
        TODO=N
        print "TODO:",TODO
        difs=map(lambda
x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool)
        dict={}
        for x in range(N):
            dict[difs[x]]=x
            mn=min(dict.keys())
        for x in range(N+1,len(difs)):
            print 'dict:',dict
            if difs[x]>mn:
                del dict[mn]
                dict[difs[x]]=x
                mn=min(dict.keys())
        list=dict.values()
        list.sort()
        TODO-=len(list)

        for cc in range(len(list)):
            dd=list.pop()
            #print "asd", dd,
            self.rpn.pop(dd)
            self.pool.pop(dd)
                
            
    

Test=RPNGen(137.03599976)    
Binary=rpn.Binary()
Unary=rpn.Unary()

for i in range(100):
    Test.Grow(100)
    #print len(Test.pool)
    
for i in range(100):
    Test.Grow(100)
    Test.Kill(100)
    print len(Test.pool)    

for i in range(99):
    Test.Kill(200)
    Test.Grow(100)
    print len(Test.pool)    


for i in range(99):
    Test.Kill(1)
    print len(Test.pool),Test.rpn


    #print len(Test.pool),Test.pool, Test.rpn
    
print Test.pool
print Test.rpn

-----------------------------------------------
rpn.py:

#module for rpn
from math import *

def Unary():
    return ['sin','cos','tan','asin','acos','atan','neg']

def Binary():
    return ['+','-','*','/','^']

def SolveRPN(rpnl):
    stack=[]
    for each in rpnl:
        try:
            num=float(each)
            stack.append(num)
        except:
            try:
                #must be an operator then.
                if each=='+':
                    stack.append(stack.pop()+stack.pop())
                elif each=='-':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2-a1)
                elif each=='*':
                    stack.append(stack.pop()*stack.pop())
                elif each=='/':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2/a1)
                elif each=='^':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2**a1)
                elif each=='cos':
                    stack[-1]=cos(stack[-1])
                elif each=='sin':
                    stack[-1]=sin(stack[-1])
                elif each=='tan':
                    stack[-1]=tan(stack[-1])
                elif each=='acos':
                    stack[-1]=acos(stack[-1])
                elif each=='asin':
                    stack[-1]=asin(stack[-1])
                elif each=='atan':
                    stack[-1]=atan(stack[-1])
                elif each=='neg':
                    stack[-1]=-1.0*stack[-1]
                else:
                    print "Unknown operation",each
            except:
                return None
    if len(stack)<>1:
        #print "Stack ended non-empty:",stack
        return None
    return stack[0]
                




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

>Comment By: Anze Slosar (anze)
Date: 2003-03-20 11:14

Message:
Logged In: YES 
user_id=447507

Operating system is RedHat 8.0 with custom 2.4.20 kernel. I
did the following:

 [anze@as280 anze]$ ldd `which python`
        libdl.so.2 => /lib/libdl.so.2 (0x4002d000)
        libpthread.so.0 => /lib/i686/libpthread.so.0
(0x40031000)
        libutil.so.1 => /lib/libutil.so.1 (0x40061000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40064000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6
glibc-2.2.93-5
[anze@as280 anze]$ 

So it seems to me that libm is from glibc-2.2.93-5. Compiler
is stock redhat gcc-3.2, but I haven't compiled anything
myself...


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-17 22:06

Message:
Logged In: YES 
user_id=31435

Which operating system and C compiler?  Since the assert() 
is checking the errno result from your platform libm's pow() 
function, the resolution of this is going to depend on which C 
library you're using.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 11:36:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 03:36:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch
Message-ID: 

Bugs item #697220, was opened at 2003-03-04 13:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Gerhard Häring (ghaering)
Summary: string.strip implementation/doc mismatch

Initial Comment:
#v+
>>> "test".strip("t")
'es'
>>> import string
>>> print string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>
#v-

*But* the Python documentation says that not only the
string *method* strip() will allow a second optional
argument, but also the strip function in the string
module.
(http://www.python.org/doc/current/lib/module-string.html)

string.strip should be changed to accept the additional
 parameter.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-20 12:36

Message:
Logged In: YES 
user_id=89016

In the patch for 2.3 a few docstrings in string.py still
mention sep instead of chars. The tests in
test/string_tests.py::MixinStrUnicodeUserStringTest.test_strip_args()
should be moved to CommonTest.test_strip() so that these
tests will be run for the string module too.

I haven't looked at the 2.2.3 patch yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-06 07:25

Message:
Logged In: YES 
user_id=33168

Gerhard, hopefully I've cleaned things up this time.  Could
you review both patches attached (one for 2.2.3, the other
for 2.3)?  I will send a message to python-dev to get
concurrence on the changes and hopefully more review.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 19:20

Message:
Logged In: YES 
user_id=33168

Thanks, you are correct.  The problem was with the string
object, not the string module.  :-(  I need to look at this
more.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-04 19:10

Message:
Logged In: YES 
user_id=163326

Neil, I don't think this was implemented in the 2.2
maintenance branch. That's why I'm reopening this. At least
for my 2.2 Pythons string.strip accepts one parameter only:

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 string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>

and

Python 2.2.2 (#1, Feb  9 2003, 13:22:07)
[GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)

Confused.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 18:55

Message:
Logged In: YES 
user_id=33168

Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before
do not.  We should really update the doc.  I thought this
was done, but apparently not.

Checked in as: libstring.tex 1.45.8.4

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 12:33:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 04:33:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order
Message-ID: 

Bugs item #705836, was opened at 2003-03-18 20:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Richard Hill (richardh2003)
Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order

Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0

This was run on an Intel platform.

>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 
+ .1
>>> v
7.9999999999999964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'

These two should be the same byte pattern (only 
reversed)!

>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)

!!!!!



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

>Comment By: Richard Hill (richardh2003)
Date: 2003-03-20 12:33

Message:
Logged In: YES 
user_id=737060

Thanks for getting back to me.

Your comment regarding IEEE formats is very interesting, I 
didn't know about this behaviour.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 05:25

Message:
Logged In: YES 
user_id=31435

Boosted priority because this is an especially bad kind of 
bug:  mysterious, subtle, and very rare ("most" in-range 
floats pack under "f" without problems; a problem 
requires that a carry out of the 25th most-significant-bit 
propagate thru a solid string of 24 1 bits).

For 2.2 I expect to check in a quick hack.  In 2.3 this code 
needs refactoring (structmodule and cPickle shouldn't have 
duplicated this delicate code)

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 19:01

Message:
Logged In: YES 
user_id=31435

Yuck.  It's a bug in not accounting for that rounding can 
spill over the original bit width.  structmodule's pack_float() 
and pack_double() both have this flaw, although the one in 
pack_double() is much subtler.  A similar cut-and-paste 
bug is in cPicke's save_float().  I'll fix all this.

Note:  while "f"'s, there's no defined relationship between either of 
those and plain "f".  "f" is platform-native in all respects.  "f" force an IEEE-like encoding, even on non-IEEE 
platforms.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 12:43:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 04:43:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion  failed, python aborts
Message-ID: 

Bugs item #705231, was opened at 2003-03-17 21:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Anze Slosar (anze)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion  failed, python aborts

Initial Comment:
This bug is reproducible with python 2.2.1 althogh it
fails only occasionally as the flow depends on random
numbers. 
It aborts by saying:

python: Objects/floatobject.c:582: float_pow: Assertion
`(*__errno_location ()) == 34' failed.
Aborted

I tried python 2.2.2 but as I try to install rpms I run
into every growing list of dependencies. I couldn't
reproduce the exact cause of the bug, but it is caused
by the following simple code (trying to invent
expressions for numbers using genetic algorithm (the
code itself is buggy in the Kill method, but I have
trouble debugging it because python crashes).

makeeq.py:

#!/usr/bin/env python
# Make equations using rpn and genetic algorithms

from random import *
from math import *
import rpn


def RanPosP(list):
    return int(uniform(0,len(list))+1)

def RanPos(list):
    return int(uniform(0,len(list)))

def AddUnary(list):
    a1=RanPosP(list)
    a2=RanPos(Unary)
    list=list[:a1]+[Unary[a2]]+list[a1:]
    return list

def AddBinary(list):
    a1=RanPosP(list)
    a2=RanPos(Binary)
    num=int(uniform(0,10))
    #print "Add binary:",list,num,rpn.Binary()[a2]
    list=list[:a1]+[num]+[Binary[a2]]+list[a1:]
    #print 'Add binary:',list
    return list

        
class RPNGen:
    def __init__(self,target):
        self.pool=[[1]]
        self.rpn=[1.0]
        self.target=target

    def GetRPN(self):
        self.rpn=map(rpn.SolveRPN,self.pool)
    
    def Grow(self,N):
        for x in range(N):
            ihave=[]
            while rpn.SolveRPN(ihave)==None:
                ml=len(self.pool)
                #print self.pool
                ii=int(uniform(0,ml))
                action=int(uniform(0,4))
                #print action
                if action==0:
                   ihave=(AddUnary(self.pool[ii]))

                elif action==1:
                    ihave=(AddBinary(self.pool[ii]))

                elif action==2:
                    jj=int(uniform(0,len(self.pool)))
                    bit=self.pool[jj]
                    a1=int(uniform(0,len(bit)))
                    a2=int(uniform(0,len(bit)))
                    if a2>a1:
                        bit=bit[a1:a2]
                    else:
                        bit=bit[a2:a1]
                    a3=int(uniform(0,len(self.pool[ii])))
                   
ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:])

                elif action==3:
                    bit=self.pool[ii]
                    a1=int(uniform(0,len(bit)))
                    a2=int(uniform(0,len(bit)))
                   
ihave=(self.pool[ii][:a1]+self.pool[ii][a2:])
            self.pool.append(ihave)
            self.rpn.append(rpn.SolveRPN(ihave))
                
        #print self.pool,self.rpn
        deletelist=[]
        for cc in range(len(self.pool)):
            if self.rpn[cc]==None:
                deletelist.append(cc)

        while len(deletelist)>0:
            cc=deletelist.pop()
            self.rpn.pop(cc)
            self.pool.pop(cc)

    def Kill(self,N):
        TODO=N
        print "TODO:",TODO
        difs=map(lambda
x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool)
        dict={}
        for x in range(N):
            dict[difs[x]]=x
            mn=min(dict.keys())
        for x in range(N+1,len(difs)):
            print 'dict:',dict
            if difs[x]>mn:
                del dict[mn]
                dict[difs[x]]=x
                mn=min(dict.keys())
        list=dict.values()
        list.sort()
        TODO-=len(list)

        for cc in range(len(list)):
            dd=list.pop()
            #print "asd", dd,
            self.rpn.pop(dd)
            self.pool.pop(dd)
                
            
    

Test=RPNGen(137.03599976)    
Binary=rpn.Binary()
Unary=rpn.Unary()

for i in range(100):
    Test.Grow(100)
    #print len(Test.pool)
    
for i in range(100):
    Test.Grow(100)
    Test.Kill(100)
    print len(Test.pool)    

for i in range(99):
    Test.Kill(200)
    Test.Grow(100)
    print len(Test.pool)    


for i in range(99):
    Test.Kill(1)
    print len(Test.pool),Test.rpn


    #print len(Test.pool),Test.pool, Test.rpn
    
print Test.pool
print Test.rpn

-----------------------------------------------
rpn.py:

#module for rpn
from math import *

def Unary():
    return ['sin','cos','tan','asin','acos','atan','neg']

def Binary():
    return ['+','-','*','/','^']

def SolveRPN(rpnl):
    stack=[]
    for each in rpnl:
        try:
            num=float(each)
            stack.append(num)
        except:
            try:
                #must be an operator then.
                if each=='+':
                    stack.append(stack.pop()+stack.pop())
                elif each=='-':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2-a1)
                elif each=='*':
                    stack.append(stack.pop()*stack.pop())
                elif each=='/':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2/a1)
                elif each=='^':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2**a1)
                elif each=='cos':
                    stack[-1]=cos(stack[-1])
                elif each=='sin':
                    stack[-1]=sin(stack[-1])
                elif each=='tan':
                    stack[-1]=tan(stack[-1])
                elif each=='acos':
                    stack[-1]=acos(stack[-1])
                elif each=='asin':
                    stack[-1]=asin(stack[-1])
                elif each=='atan':
                    stack[-1]=atan(stack[-1])
                elif each=='neg':
                    stack[-1]=-1.0*stack[-1]
                else:
                    print "Unknown operation",each
            except:
                return None
    if len(stack)<>1:
        #print "Stack ended non-empty:",stack
        return None
    return stack[0]
                




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

>Comment By: Anze Slosar (anze)
Date: 2003-03-20 12:43

Message:
Logged In: YES 
user_id=447507

Crashes with python 2.2.2 as well, but seems to work under
Solaris.

Here's what gdb says:

(gdb) [anze@APPCH numbers]> gdb `which python2` core.1406
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `python2 ./makeeq.py'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libpthread.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/libutil.so.1...(no debugging
symbols found)...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/i686/libm.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging
symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from
/usr/lib/python2.2/lib-dynload/structmodule.so...
(no debugging symbols found)...done.
Loaded symbols for
/usr/lib/python2.2/lib-dynload/structmodule.so
Reading symbols from
/usr/lib/python2.2/lib-dynload/_codecsmodule.so...
(no debugging symbols found)...done.
Loaded symbols for
/usr/lib/python2.2/lib-dynload/_codecsmodule.so
Reading symbols from
/usr/lib/python2.2/lib-dynload/mathmodule.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so
Reading symbols from
/usr/lib/python2.2/lib-dynload/timemodule.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so
#0  0x42029331 in kill () from /lib/i686/libc.so.6
(gdb) w
Ambiguous command "w": watch, whatis, where, while,
while-stepping, ws.
(gdb) whe
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x40030bdb in raise () from /lib/i686/libpthread.so.0
#2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3  0x42022ecb in __assert_fail () from /lib/i686/libc.so.6
#4  0x080befeb in float_pow ()
#5  0x080af00f in ternary_op ()
#6  0x080af6fc in PyNumber_Power ()
#7  0x08077dda in eval_frame ()
#8  0x0807b49c in PyEval_EvalCodeEx ()
#9  0x0807c4fe in fast_function ()
#10 0x0807a367 in eval_frame ()
#11 0x0807b49c in PyEval_EvalCodeEx ()
#12 0x0807c4fe in fast_function ()
#13 0x0807a367 in eval_frame ()
#14 0x0807b49c in PyEval_EvalCodeEx ()
#15 0x08077491 in PyEval_EvalCode ()
#16 0x080970a1 in run_node ()
#17 0x08096176 in PyRun_SimpleFileExFlags ()
#18 0x08095b9f in PyRun_AnyFileExFlags ()
#19 0x08053c42 in Py_Main ()
#20 0x08053393 in main ()
#21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) 


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

Comment By: Anze Slosar (anze)
Date: 2003-03-20 11:14

Message:
Logged In: YES 
user_id=447507

Operating system is RedHat 8.0 with custom 2.4.20 kernel. I
did the following:

 [anze@as280 anze]$ ldd `which python`
        libdl.so.2 => /lib/libdl.so.2 (0x4002d000)
        libpthread.so.0 => /lib/i686/libpthread.so.0
(0x40031000)
        libutil.so.1 => /lib/libutil.so.1 (0x40061000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40064000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6
glibc-2.2.93-5
[anze@as280 anze]$ 

So it seems to me that libm is from glibc-2.2.93-5. Compiler
is stock redhat gcc-3.2, but I haven't compiled anything
myself...


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-17 22:06

Message:
Logged In: YES 
user_id=31435

Which operating system and C compiler?  Since the assert() 
is checking the errno result from your platform libm's pow() 
function, the resolution of this is going to depend on which C 
library you're using.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 12:58:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 04:58:24 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-684542 ] dict setdefault lazy evaluation
Message-ID: 

Feature Requests item #684542, was opened at 2003-02-11 13:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=684542&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict setdefault lazy evaluation

Initial Comment:
Reading "python cookbook" I reach a very intelligent
dictionary construction: to use dictionary "setdefault"
to avoid a "get" or a "try...except".

Nevertheless current "setdefault" behaviour is
questionable, since it evaluates the default value when
it is not necessary. In my mind, "setdefault" should
evaluate the default value when it need to use it, not
ALWAYS. Example:

>>> a={}
>>> def b() :
...   print "hi!"
...   return 1
... 
>>> a.setdefault("hola","hello")
hello
>>> print a
{'hola': 'hello'}
>>> a.setdefault("hola",b())
hi!
'hello'

In the example, the "setdefault" evaluation is not
necessary since 'a["hola"]' exists. But the default
function is called, although its return value will be
ignored.

This behaviour is not intuitive and I think it should
be changed or, at least, documented. The change would
be very welcome when the "setdefault" default code is
expensive, like my application. In any case, the change
would be ALWAYS more efficient, even in the tipical
"[]" case.

Perhaps a "form __future__ import setdefaultNG" would
be necessary to help to update legacy code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=684542&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 12:59:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 04:59:06 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-684542 ] dict setdefault lazy evaluation
Message-ID: 

Feature Requests item #684542, was opened at 2003-02-11 13:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=684542&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict setdefault lazy evaluation

Initial Comment:
Reading "python cookbook" I reach a very intelligent
dictionary construction: to use dictionary "setdefault"
to avoid a "get" or a "try...except".

Nevertheless current "setdefault" behaviour is
questionable, since it evaluates the default value when
it is not necessary. In my mind, "setdefault" should
evaluate the default value when it need to use it, not
ALWAYS. Example:

>>> a={}
>>> def b() :
...   print "hi!"
...   return 1
... 
>>> a.setdefault("hola","hello")
hello
>>> print a
{'hola': 'hello'}
>>> a.setdefault("hola",b())
hi!
'hello'

In the example, the "setdefault" evaluation is not
necessary since 'a["hola"]' exists. But the default
function is called, although its return value will be
ignored.

This behaviour is not intuitive and I think it should
be changed or, at least, documented. The change would
be very welcome when the "setdefault" default code is
expensive, like my application. In any case, the change
would be ALWAYS more efficient, even in the tipical
"[]" case.

Perhaps a "form __future__ import setdefaultNG" would
be necessary to help to update legacy code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=684542&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 13:40:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 05:40:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-19 14:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

>Comment By: Alexander Miseler (amiseler)
Date: 2003-03-20 14:40

Message:
Logged In: YES 
user_id=693638

and to say something FOR noop:
tim_one: "(nobody would write to stdout or stderr
*intending* the output be lost)"

yes, but someone would use print in an application and still
intend this application to run on any platform supported by
python.
its not really intuitive for someone programming under linux
that the print statement may limit the portability.

btw: the microsoft implementations (visual studio) of printf
and cout seem to be noops for non-console applications.
no idea how other windows compilers (mingw?) handle this.

i would consider it best, to make sys.stdout.write a noop
but to provide some other means to inquire the availability
of text output.

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

Comment By: Alexander Miseler (amiseler)
Date: 2003-03-20 10:19

Message:
Logged In: YES 
user_id=693638

then please throw a meaningful exception at first byte
written, not an obscure exception after 4096 bytes written.


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 05:17

Message:
Logged In: YES 
user_id=31435

I can swing either way on this, or even a third:  open text 
files stdout.txt and stderr.txt in the current directory then.  
That's really aiming at a different irritation, though, that 
tracebacks end up in the bit bucket by default under 
pythonw.

BTW, making stdout and stderr /dev/null workalikes is 
least attractive to me (nobody would write to stdout or 
stderr *intending* the output be lost).  I'm (barely) OK with 
letting it stay as it is, because that just reflects Windows 
reality.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-03-20 00:51

Message:
Logged In: YES 
user_id=14198

I struck this years ago, but was in a quandry.  On one hand,
sys.stdout *is* invalid, and I see no reason why Python
should mask these errors.  There may be real applications
where this failure *must* be reported to the program rather
than simply consumed.

However, I see the point that print is so basic that is
should never fail.  To my mind, the first point outweighs
the first, and the problem is fairly simply solved (see if
sys.stdout is invalid, and if so, open a file and set it to
that).

So I am afraid that, no, I don't give a rats .  Unless
conivenced otherwise (ie, by Tim or Guido) I will close this
as "not a bug" in a week or so.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 18:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 14:26:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 06:26:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-706546 ] u''.translate not documented
Message-ID: 

Bugs item #706546, was opened at 2003-03-19 16:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
Assigned to: Nobody/Anonymous (nobody)
Summary: u''.translate not documented

Initial Comment:
The behaviour of u''.translate is significantly
different from ''.translate, yet the difference is not
reflected in the documentation.

- ''.translate takes one or two arguments, one a table
of 256 characters for the translation target and the
other a string containing characters to be removed.

- u''.translate only takes on argument, which is a
mapping from unicode ordinal to unicode ordinal,
ustring or None.

See also print u''.translate.__doc__

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

>Comment By: Martijn Pieters (mjpieters)
Date: 2003-03-20 09:26

Message:
Logged In: YES 
user_id=116747

No, the documentation on u''.translate is *not present*. The
Python Library Reference makes no mention of a difference. See:

  http://www.python.org/doc/current/lib/string-methods.html

I don't really care how it is of little use, I just need the
documentation to be up to date so I don't have to scratch my
head why I get this weird error that translate only takes
one argument; as it turns out the strings I was calling this
on were unicode strings.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-03-20 04:15

Message:
Logged In: YES 
user_id=38388

Isn't the documentation clear enough about the difference ?

Note that u.translate() is not really all that useful. You
are much
better off with writing your own charmap based codec which
is not really difficult: just take a look at e.g. cp1251.py.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 16:07:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 08:07:09 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706970 ] Including python-codecs codecs in standard distribution?
Message-ID: 

Feature Requests item #706970, was opened at 2003-03-21 00:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Stabell (bjoerns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Including python-codecs codecs in standard distribution?

Initial Comment:
Are there any plans to include the python-codecs in the 
standard distribution?  They are Chinese and Japanese 
encodings, very useful if you live in China or Japan, 
which quite a few people do :)  -- Imagine having to 
download ASCII encoding separately.

What's stopping the inclusion, if anything?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 17:53:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 09:53:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-706546 ] u''.translate not documented
Message-ID: 

Bugs item #706546, was opened at 2003-03-19 22:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martijn Pieters (mjpieters)
Assigned to: Nobody/Anonymous (nobody)
Summary: u''.translate not documented

Initial Comment:
The behaviour of u''.translate is significantly
different from ''.translate, yet the difference is not
reflected in the documentation.

- ''.translate takes one or two arguments, one a table
of 256 characters for the translation target and the
other a string containing characters to be removed.

- u''.translate only takes on argument, which is a
mapping from unicode ordinal to unicode ordinal,
ustring or None.

See also print u''.translate.__doc__

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-03-20 18:53

Message:
Logged In: YES 
user_id=38388

I see. In that case, I'd suggest you provide a patch to fill up
the gaps.

Thanks.

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

Comment By: Martijn Pieters (mjpieters)
Date: 2003-03-20 15:26

Message:
Logged In: YES 
user_id=116747

No, the documentation on u''.translate is *not present*. The
Python Library Reference makes no mention of a difference. See:

  http://www.python.org/doc/current/lib/string-methods.html

I don't really care how it is of little use, I just need the
documentation to be up to date so I don't have to scratch my
head why I get this weird error that translate only takes
one argument; as it turns out the strings I was calling this
on were unicode strings.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-03-20 10:15

Message:
Logged In: YES 
user_id=38388

Isn't the documentation clear enough about the difference ?

Note that u.translate() is not really all that useful. You
are much
better off with writing your own charmap based codec which
is not really difficult: just take a look at e.g. cp1251.py.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 18:37:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 10:37:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-700798 ] fixes and cleanups for descriptor info
Message-ID: 

Bugs item #700798, was opened at 2003-03-10 07:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700798&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fixes and cleanups for descriptor info

Initial Comment:
fixes

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-03-20 13:37

Message:
Logged In: YES 
user_id=3066

Committed as part of Doc/ref/ref3.tex revision 1.102;
backported portions for Python 2.2.3 as revision 1.82.4.8.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700798&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 18:43:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 10:43:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib
Message-ID: 

Bugs item #666219, was opened at 2003-01-11 08:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Jeremy Hylton (jhylton)
Summary: AssertionErrors in httplib

Initial Comment:
I've recently noticed AssertionErrors being raised by
httplib.LineAndFileWrapper.read().  It happens reliably when the server
exits unexpectedly.  Here's an example of an AssertionError in an 
xmlrpclib client when I kill the server it's talking to:

    Traceback (most recent call last):
      File "qa.py", line 22, in ?
        x = s.query(tmpl, st, en, radius, age)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__
        return self.__send(self.__name, args)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request
        verbose=self.__verbose
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request
        return self._parse_response(h.getfile(), sock)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response
        response = file.read(1024)
      File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read
        assert not self._line_consumed and self._line_left
    AssertionError

I don't see a problem with raising an exception in this situation.  I just
wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code).  If an exception
is being raised because the server went away, I think it would be 
better to raise IncompleteRead.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-03-20 12:43

Message:
Logged In: YES 
user_id=44345

Sorry for the delay on this.  I think I'm closing in on the
problem.  I've been using Tim O'Malley's timeoutsocket
module for quite awhile.  I noticed the same problem today
when using the new timeout feature in the socket module.
Libraries like xmlrpclib use makefile() to get a file object
to play with.  File objects don't play well with timeouts
because the socket is in non-blocking mode.  I think what
happens here is that the first line of HTTPResponse.
_read_status sets line to the empty string because of the
timeout setting.  Tracing through the code which follows
makes it clear that control will wind up in the HTTP/0.9
chunk of code.

Maybe it's worth adding a test for line == "" after the
readline() call:

        line = self.fp.readline()
        if self.debuglevel > 0:
            print "reply:", repr(line)
        if line == "":
            raise BadStatusLine(line)

That would distinguish an error reading from an 0.9 server
(which would return something with that first readline()
call).

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-31 08:13

Message:
Logged In: YES 
user_id=44345

No, sorry, I haven't looked more deeply into the problem.  I did investigate
far enough to also see that the code was in the HTTP/0.9 weeds and am
befuddled about why it would be there.  It's using the vanilla xmlrpclib
module at both ends.  I'll try to spend a little time today.

S

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-31 08:07

Message:
Logged In: YES 
user_id=31392

Any more info Skip?


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-14 15:18

Message:
Logged In: YES 
user_id=31392

It's definitely the case that an AssertionError shouldn't be
raised.  It was my intention that the assert never fail.  Do
you know which part of the assert fails?  Perhaps you could
change the assert to print the values of _line_consumed and
_line_left and run some more tests.
I can't figure out how this goes wrong.

Also, do you know when the server is sending an HTTP/0.9
response?  I wonder if there's a bug somewhere else and the
client is guessing the wrong protocol version for the response.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 18:48:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 10:48:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order
Message-ID: 

Bugs item #705836, was opened at 2003-03-18 15:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470

>Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Richard Hill (richardh2003)
Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order

Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0

This was run on an Intel platform.

>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 
+ .1
>>> v
7.9999999999999964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'

These two should be the same byte pattern (only 
reversed)!

>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)

!!!!!



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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-20 13:48

Message:
Logged In: YES 
user_id=31435

Fixed.  In the 2.2 branch:

Lib/test/test_struct.py; new revision: 1.14.12.1
Misc/NEWS; new revision: 1.337.2.4.2.68
Modules/cPickle.c; new revision: 2.73.2.1.2.4
Modules/structmodule.c; new revision: 2.51.8.2

For 2.3:

Lib/test/test_struct.py; new revision: 1.17
Misc/NEWS; new revision: 1.700
Modules/cPickle.c; new revision: 2.141
Modules/structmodule.c; new revision: 2.58

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

Comment By: Richard Hill (richardh2003)
Date: 2003-03-20 07:33

Message:
Logged In: YES 
user_id=737060

Thanks for getting back to me.

Your comment regarding IEEE formats is very interesting, I 
didn't know about this behaviour.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 00:25

Message:
Logged In: YES 
user_id=31435

Boosted priority because this is an especially bad kind of 
bug:  mysterious, subtle, and very rare ("most" in-range 
floats pack under "f" without problems; a problem 
requires that a carry out of the 25th most-significant-bit 
propagate thru a solid string of 24 1 bits).

For 2.2 I expect to check in a quick hack.  In 2.3 this code 
needs refactoring (structmodule and cPickle shouldn't have 
duplicated this delicate code)

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 14:01

Message:
Logged In: YES 
user_id=31435

Yuck.  It's a bug in not accounting for that rounding can 
spill over the original bit width.  structmodule's pack_float() 
and pack_double() both have this flaw, although the one in 
pack_double() is much subtler.  A similar cut-and-paste 
bug is in cPicke's save_float().  I'll fix all this.

Note:  while "f"'s, there's no defined relationship between either of 
those and plain "f".  "f" is platform-native in all respects.  "f" force an IEEE-like encoding, even on non-IEEE 
platforms.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 18:58:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 10:58:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protos
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: timeouts incompatible w/ line-oriented protos

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Thu Mar 20 22:16:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 14:16:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-682813 ] dircache.listdir doesn't signal error
Message-ID: 

Bugs item #682813, was opened at 2003-02-08 10:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682813&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: dircache.listdir doesn't signal error

Initial Comment:
dircache.listidir('some_non_existent_directory') simply
returns an empty list.  That's inconsistent with os.listdir
which raises an OSError exception.  I think
dircache.listdir
should also raise an exception if the directory can't
be read.
At minimum, though, the difference should be documented.


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

Comment By: Michael Stone (mbrierst)
Date: 2003-03-20 22:16

Message:
Logged In: YES 
user_id=670441

I agree.  I posted patch #707167 to
make it raise the error.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682813&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 03:28:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 19:28:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX
Message-ID: 

Bugs item #678259, was opened at 2003-01-31 13:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: locale.getpreferredencoding fails on AIX

Initial Comment:

The problem is setting LC_CTYPE to an empty string:

>>> locale.setlocale(locale.LC_CTYPE, '')
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/neal/python/dist/aix/Lib/locale.py", line 
381, in setlocale
    return _setlocale(category, locale)
locale.Error: locale setting not supported

Putting a try/except around the setlocale call in 
getpreferredencoding allows the test to pass.  I don't 
know if this is correct.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-20 22:28

Message:
Logged In: YES 
user_id=33168

The problem was that the setlocale in Lib/locale.py was
being used, not from Modules/_localemodule.c.  In the python
version, it does not allow an empty string.  Seems like this
should be changed, do you agree?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-03 18:11

Message:
Logged In: YES 
user_id=21627

What are the relevant environment settings? According to

http://nscp.upenn.edu/aix4.3html/libs/basetrf2/setlocale.htm

specifying "" as the second argument of setlocale is
supported, and means the same thing as it does on all other
systems: take locale settings from the user preferences.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 07:10:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 20 Mar 2003 23:10:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX
Message-ID: 

Bugs item #678259, was opened at 2003-01-31 19:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: locale.getpreferredencoding fails on AIX

Initial Comment:

The problem is setting LC_CTYPE to an empty string:

>>> locale.setlocale(locale.LC_CTYPE, '')
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/neal/python/dist/aix/Lib/locale.py", line 
381, in setlocale
    return _setlocale(category, locale)
locale.Error: locale setting not supported

Putting a try/except around the setlocale call in 
getpreferredencoding allows the test to pass.  I don't 
know if this is correct.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 08:10

Message:
Logged In: YES 
user_id=21627

I don't understand. In the traceback, it says that
_setlocale is invoked, which is the function from
_localemodule. Since the locale argument is still an empty
string, it still seems to be a flaw in the AIX
implementation, or else the user has environment settings
which are not supported by AIX.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-21 04:28

Message:
Logged In: YES 
user_id=33168

The problem was that the setlocale in Lib/locale.py was
being used, not from Modules/_localemodule.c.  In the python
version, it does not allow an empty string.  Seems like this
should be changed, do you agree?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-04 00:11

Message:
Logged In: YES 
user_id=21627

What are the relevant environment settings? According to

http://nscp.upenn.edu/aix4.3html/libs/basetrf2/setlocale.htm

specifying "" as the second argument of setlocale is
supported, and means the same thing as it does on all other
systems: take locale settings from the user preferences.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 13:37:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 05:37:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-704919 ] Problems building python with tkinter on HPUX...
Message-ID: 

Bugs item #704919, was opened at 2003-03-17 12:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jayce Piel (jayce)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems building python with tkinter on HPUX...

Initial Comment:
I have some problems when trying to install python on a
HPUX 10.20 system.
All seems to go well during the compiling and during
the installation process, but when I try to use tkinter
in my new python with an "import _tkinter", i have the
following lines :
Python 2.2.2 (#2, Mar 17 2003, 04:36:02)
[GCC 2.95.2 19991024 (release)] on hp-ux10
Type "help", "copyright", "credits" or "license" for
more information.
>>> import _tkinter
/usr/lib/dld.sl: Unresolved symbol: acos (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: asin (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: atan (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: cosh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: log10 (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: sinh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: tan (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: tanh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclTraceExec (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclProcBodyType (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclFreeObjList (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclExecutableName (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
Tcl_FindExecutable (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
zsh: abort (core dumped)  python

I have a python1.5/tkinter that works with tcl/tk 8.0p2...
When trying to compile with this version of tcl/tk, i
had errors with the tkinter module compilation.
Then, I tried to compile a tcl/tk 8.4.2, or even use a
binary-package of a tcl/tk 8.2.1, but in both cases I
have the above errors when running...




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

>Comment By: Jayce Piel (jayce)
Date: 2003-03-21 14:37

Message:
Logged In: YES 
user_id=5496

After different tries, I found that adding "-L/usr/lib -lm"
as parameters of "ld -b" solved THIS problem...

But I still have a problem... Now, when laucnhing
Tkinter._test(), I have the error message  :
"/usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code)  from
/usr/local/lib/libtcl8.4.sl"
And a core dumped...
I have compiled tcl/tk without threads, and python without
threads too...


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:48

Message:
Logged In: YES 
user_id=33168

The problem appears to be that -lm (ie the math library)
needs to be linked, but is not.  I do not have access to a
10.20 machine.  It also looks like the tcl library may not
be found.  Perhaps there's a library search problem?  Jayce,
if you could produce a patch that works for you, I can check
in a fix.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 14:51:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 06:51:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-704919 ] Problems building python with tkinter on HPUX...
Message-ID: 

Bugs item #704919, was opened at 2003-03-17 12:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jayce Piel (jayce)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems building python with tkinter on HPUX...

Initial Comment:
I have some problems when trying to install python on a
HPUX 10.20 system.
All seems to go well during the compiling and during
the installation process, but when I try to use tkinter
in my new python with an "import _tkinter", i have the
following lines :
Python 2.2.2 (#2, Mar 17 2003, 04:36:02)
[GCC 2.95.2 19991024 (release)] on hp-ux10
Type "help", "copyright", "credits" or "license" for
more information.
>>> import _tkinter
/usr/lib/dld.sl: Unresolved symbol: acos (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: asin (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: atan (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: cosh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: log10 (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: sinh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: tan (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: tanh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclTraceExec (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclProcBodyType (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclFreeObjList (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclExecutableName (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
Tcl_FindExecutable (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
zsh: abort (core dumped)  python

I have a python1.5/tkinter that works with tcl/tk 8.0p2...
When trying to compile with this version of tcl/tk, i
had errors with the tkinter module compilation.
Then, I tried to compile a tcl/tk 8.4.2, or even use a
binary-package of a tcl/tk 8.2.1, but in both cases I
have the above errors when running...




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

>Comment By: Jayce Piel (jayce)
Date: 2003-03-21 15:51

Message:
Logged In: YES 
user_id=5496

OK, all works now...
Here are what I need to modify :
In the Makefile of tcl 8.4.2 and in the Makefile of tk 8.4.2 :
SHLIB_LD                = gcc -shared -fPIC
LD_SEARCH_FLAGS =

In the Makefile of Python :
LDSHARED=       ld -b -L/usr/lib -lm
-L/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91
.60 -lgcc
BLDSHARED=      ld -b -L/usr/lib -lm
-L/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91
.60 -lgcc


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

Comment By: Jayce Piel (jayce)
Date: 2003-03-21 14:37

Message:
Logged In: YES 
user_id=5496

After different tries, I found that adding "-L/usr/lib -lm"
as parameters of "ld -b" solved THIS problem...

But I still have a problem... Now, when laucnhing
Tkinter._test(), I have the error message  :
"/usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code)  from
/usr/local/lib/libtcl8.4.sl"
And a core dumped...
I have compiled tcl/tk without threads, and python without
threads too...


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:48

Message:
Logged In: YES 
user_id=33168

The problem appears to be that -lm (ie the math library)
needs to be linked, but is not.  I do not have access to a
10.20 machine.  It also looks like the tcl library may not
be found.  Perhaps there's a library search problem?  Jayce,
if you could produce a patch that works for you, I can check
in a fix.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 15:36:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 07:36:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX
Message-ID: 

Bugs item #678259, was opened at 2003-01-31 13:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: locale.getpreferredencoding fails on AIX

Initial Comment:

The problem is setting LC_CTYPE to an empty string:

>>> locale.setlocale(locale.LC_CTYPE, '')
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/neal/python/dist/aix/Lib/locale.py", line 
381, in setlocale
    return _setlocale(category, locale)
locale.Error: locale setting not supported

Putting a try/except around the setlocale call in 
getpreferredencoding allows the test to pass.  I don't 
know if this is correct.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-21 10:36

Message:
Logged In: YES 
user_id=33168

The traceback from the original report was not the same as
my last comment.  The original problem seems to be gone.  I
don't know what changed, but the localemodule builds and
tests correctly.  However, before getting the module to
build, I was using the python version.  The python version
of setlocale() doesn't support setting a value to an empty
string.  Based on your first comment, it seems the python
version (line 72 of locale.py) should allow the value to be
either '' or 'C'.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 02:10

Message:
Logged In: YES 
user_id=21627

I don't understand. In the traceback, it says that
_setlocale is invoked, which is the function from
_localemodule. Since the locale argument is still an empty
string, it still seems to be a flaw in the AIX
implementation, or else the user has environment settings
which are not supported by AIX.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-20 22:28

Message:
Logged In: YES 
user_id=33168

The problem was that the setlocale in Lib/locale.py was
being used, not from Modules/_localemodule.c.  In the python
version, it does not allow an empty string.  Seems like this
should be changed, do you agree?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-03 18:11

Message:
Logged In: YES 
user_id=21627

What are the relevant environment settings? According to

http://nscp.upenn.edu/aix4.3html/libs/basetrf2/setlocale.htm

specifying "" as the second argument of setlocale is
supported, and means the same thing as it does on all other
systems: take locale settings from the user preferences.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 15:52:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 07:52:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-707576 ] -i -u options give SyntaxError on Windows
Message-ID: 

Bugs item #707576, was opened at 2003-03-21 15:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Tim Peters (tim_one)
Summary: -i -u options give SyntaxError on Windows

Initial Comment:
C:\>python -i -u
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.
>>> print 1
  File "", line 1
    print 1
           ^
SyntaxError: invalid syntax
>>>

...and this behaviour continues, no mater what
statement you enter.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 16:30:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 08:30:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-707576 ] -i -u options give SyntaxError on Windows
Message-ID: 

Bugs item #707576, was opened at 2003-03-21 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Tim Peters (tim_one)
Summary: -i -u options give SyntaxError on Windows

Initial Comment:
C:\>python -i -u
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.
>>> print 1
  File "", line 1
    print 1
           ^
SyntaxError: invalid syntax
>>>

...and this behaviour continues, no mater what
statement you enter.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-21 11:30

Message:
Logged In: YES 
user_id=31435

Why do you call this a bug?  -u forces stdin into binary mode, 
and the Python grammar does not allow \r\n line endings in 
program text (it never has, BTW).  Program text has to come 
from a file opened in text mode on Windows, and what you're 
seeing here is the same as what you'd see if you did

f = open('some_python_program.py', 'rb')
exec f.read()

on Windows.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 17:20:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 09:20:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-705231 ] Assertion  failed, python aborts
Message-ID: 

Bugs item #705231, was opened at 2003-03-17 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Anze Slosar (anze)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion  failed, python aborts

Initial Comment:
This bug is reproducible with python 2.2.1 althogh it
fails only occasionally as the flow depends on random
numbers. 
It aborts by saying:

python: Objects/floatobject.c:582: float_pow: Assertion
`(*__errno_location ()) == 34' failed.
Aborted

I tried python 2.2.2 but as I try to install rpms I run
into every growing list of dependencies. I couldn't
reproduce the exact cause of the bug, but it is caused
by the following simple code (trying to invent
expressions for numbers using genetic algorithm (the
code itself is buggy in the Kill method, but I have
trouble debugging it because python crashes).

makeeq.py:

#!/usr/bin/env python
# Make equations using rpn and genetic algorithms

from random import *
from math import *
import rpn


def RanPosP(list):
    return int(uniform(0,len(list))+1)

def RanPos(list):
    return int(uniform(0,len(list)))

def AddUnary(list):
    a1=RanPosP(list)
    a2=RanPos(Unary)
    list=list[:a1]+[Unary[a2]]+list[a1:]
    return list

def AddBinary(list):
    a1=RanPosP(list)
    a2=RanPos(Binary)
    num=int(uniform(0,10))
    #print "Add binary:",list,num,rpn.Binary()[a2]
    list=list[:a1]+[num]+[Binary[a2]]+list[a1:]
    #print 'Add binary:',list
    return list

        
class RPNGen:
    def __init__(self,target):
        self.pool=[[1]]
        self.rpn=[1.0]
        self.target=target

    def GetRPN(self):
        self.rpn=map(rpn.SolveRPN,self.pool)
    
    def Grow(self,N):
        for x in range(N):
            ihave=[]
            while rpn.SolveRPN(ihave)==None:
                ml=len(self.pool)
                #print self.pool
                ii=int(uniform(0,ml))
                action=int(uniform(0,4))
                #print action
                if action==0:
                   ihave=(AddUnary(self.pool[ii]))

                elif action==1:
                    ihave=(AddBinary(self.pool[ii]))

                elif action==2:
                    jj=int(uniform(0,len(self.pool)))
                    bit=self.pool[jj]
                    a1=int(uniform(0,len(bit)))
                    a2=int(uniform(0,len(bit)))
                    if a2>a1:
                        bit=bit[a1:a2]
                    else:
                        bit=bit[a2:a1]
                    a3=int(uniform(0,len(self.pool[ii])))
                   
ihave=(self.pool[ii][:a3]+bit+self.pool[ii][a3:])

                elif action==3:
                    bit=self.pool[ii]
                    a1=int(uniform(0,len(bit)))
                    a2=int(uniform(0,len(bit)))
                   
ihave=(self.pool[ii][:a1]+self.pool[ii][a2:])
            self.pool.append(ihave)
            self.rpn.append(rpn.SolveRPN(ihave))
                
        #print self.pool,self.rpn
        deletelist=[]
        for cc in range(len(self.pool)):
            if self.rpn[cc]==None:
                deletelist.append(cc)

        while len(deletelist)>0:
            cc=deletelist.pop()
            self.rpn.pop(cc)
            self.pool.pop(cc)

    def Kill(self,N):
        TODO=N
        print "TODO:",TODO
        difs=map(lambda
x,y:abs(x-self.target)-len(self.pool)/10.0,self.rpn,self.pool)
        dict={}
        for x in range(N):
            dict[difs[x]]=x
            mn=min(dict.keys())
        for x in range(N+1,len(difs)):
            print 'dict:',dict
            if difs[x]>mn:
                del dict[mn]
                dict[difs[x]]=x
                mn=min(dict.keys())
        list=dict.values()
        list.sort()
        TODO-=len(list)

        for cc in range(len(list)):
            dd=list.pop()
            #print "asd", dd,
            self.rpn.pop(dd)
            self.pool.pop(dd)
                
            
    

Test=RPNGen(137.03599976)    
Binary=rpn.Binary()
Unary=rpn.Unary()

for i in range(100):
    Test.Grow(100)
    #print len(Test.pool)
    
for i in range(100):
    Test.Grow(100)
    Test.Kill(100)
    print len(Test.pool)    

for i in range(99):
    Test.Kill(200)
    Test.Grow(100)
    print len(Test.pool)    


for i in range(99):
    Test.Kill(1)
    print len(Test.pool),Test.rpn


    #print len(Test.pool),Test.pool, Test.rpn
    
print Test.pool
print Test.rpn

-----------------------------------------------
rpn.py:

#module for rpn
from math import *

def Unary():
    return ['sin','cos','tan','asin','acos','atan','neg']

def Binary():
    return ['+','-','*','/','^']

def SolveRPN(rpnl):
    stack=[]
    for each in rpnl:
        try:
            num=float(each)
            stack.append(num)
        except:
            try:
                #must be an operator then.
                if each=='+':
                    stack.append(stack.pop()+stack.pop())
                elif each=='-':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2-a1)
                elif each=='*':
                    stack.append(stack.pop()*stack.pop())
                elif each=='/':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2/a1)
                elif each=='^':
                    a1=stack.pop()
                    a2=stack.pop()
                    stack.append(a2**a1)
                elif each=='cos':
                    stack[-1]=cos(stack[-1])
                elif each=='sin':
                    stack[-1]=sin(stack[-1])
                elif each=='tan':
                    stack[-1]=tan(stack[-1])
                elif each=='acos':
                    stack[-1]=acos(stack[-1])
                elif each=='asin':
                    stack[-1]=asin(stack[-1])
                elif each=='atan':
                    stack[-1]=atan(stack[-1])
                elif each=='neg':
                    stack[-1]=-1.0*stack[-1]
                else:
                    print "Unknown operation",each
            except:
                return None
    if len(stack)<>1:
        #print "Stack ended non-empty:",stack
        return None
    return stack[0]
                




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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-21 12:20

Message:
Logged In: YES 
user_id=31435

OK, that's some progress.  We don't really have any use for a 
traceback -- it's clear where the code is dying.  The platform 
pow() is setting an unexpected errno value on a call to pow().  
What we need to know:

1. What were the inputs to pow()?
2. What is errno's value?  We know it's not 0 and we know it's 
not ERANGE.  I can't think of any other value that makes 
sense (so I'm asserting too ).

Note that this must be triggered by your code line:

    stack.append(a2**a1) 

so you could just

    print repr(a2), repr(a1)

before that line, and the last output before the program dies 
must show the inputs the platform pow() is choking on.

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

Comment By: Anze Slosar (anze)
Date: 2003-03-20 07:43

Message:
Logged In: YES 
user_id=447507

Crashes with python 2.2.2 as well, but seems to work under
Solaris.

Here's what gdb says:

(gdb) [anze@APPCH numbers]> gdb `which python2` core.1406
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `python2 ./makeeq.py'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libpthread.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/libutil.so.1...(no debugging
symbols found)...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/i686/libm.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging
symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from
/usr/lib/python2.2/lib-dynload/structmodule.so...
(no debugging symbols found)...done.
Loaded symbols for
/usr/lib/python2.2/lib-dynload/structmodule.so
Reading symbols from
/usr/lib/python2.2/lib-dynload/_codecsmodule.so...
(no debugging symbols found)...done.
Loaded symbols for
/usr/lib/python2.2/lib-dynload/_codecsmodule.so
Reading symbols from
/usr/lib/python2.2/lib-dynload/mathmodule.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/mathmodule.so
Reading symbols from
/usr/lib/python2.2/lib-dynload/timemodule.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/timemodule.so
#0  0x42029331 in kill () from /lib/i686/libc.so.6
(gdb) w
Ambiguous command "w": watch, whatis, where, while,
while-stepping, ws.
(gdb) whe
#0  0x42029331 in kill () from /lib/i686/libc.so.6
#1  0x40030bdb in raise () from /lib/i686/libpthread.so.0
#2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
#3  0x42022ecb in __assert_fail () from /lib/i686/libc.so.6
#4  0x080befeb in float_pow ()
#5  0x080af00f in ternary_op ()
#6  0x080af6fc in PyNumber_Power ()
#7  0x08077dda in eval_frame ()
#8  0x0807b49c in PyEval_EvalCodeEx ()
#9  0x0807c4fe in fast_function ()
#10 0x0807a367 in eval_frame ()
#11 0x0807b49c in PyEval_EvalCodeEx ()
#12 0x0807c4fe in fast_function ()
#13 0x0807a367 in eval_frame ()
#14 0x0807b49c in PyEval_EvalCodeEx ()
#15 0x08077491 in PyEval_EvalCode ()
#16 0x080970a1 in run_node ()
#17 0x08096176 in PyRun_SimpleFileExFlags ()
#18 0x08095b9f in PyRun_AnyFileExFlags ()
#19 0x08053c42 in Py_Main ()
#20 0x08053393 in main ()
#21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) 


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

Comment By: Anze Slosar (anze)
Date: 2003-03-20 06:14

Message:
Logged In: YES 
user_id=447507

Operating system is RedHat 8.0 with custom 2.4.20 kernel. I
did the following:

 [anze@as280 anze]$ ldd `which python`
        libdl.so.2 => /lib/libdl.so.2 (0x4002d000)
        libpthread.so.0 => /lib/i686/libpthread.so.0
(0x40031000)
        libutil.so.1 => /lib/libutil.so.1 (0x40061000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40064000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[anze@as280 anze]$ rpm -qf /lib/i686/libm.so.6
glibc-2.2.93-5
[anze@as280 anze]$ 

So it seems to me that libm is from glibc-2.2.93-5. Compiler
is stock redhat gcc-3.2, but I haven't compiled anything
myself...


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-17 17:06

Message:
Logged In: YES 
user_id=31435

Which operating system and C compiler?  Since the assert() 
is checking the errno result from your platform libm's pow() 
function, the resolution of this is going to depend on which C 
library you're using.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705231&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 18:02:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 10:02:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
>Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 12:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 18:04:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 10:04:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-704996 ] HTMLParser fails on 
Message-ID: 

Bugs item #704996, was opened at 2003-03-17 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704996&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: gary aviv (aaii1025)
>Assigned to: Martin v. Löwis (loewis)
Summary: HTMLParser fails on 

Initial Comment:
HTMLParser can't handle constructs such as:


...


which is found in MS Word documents saved as HTML.

The problem is in markupbase.py  

Suggest the follwoing patch:

diff -u /usr/local/lib/python2.2/markupbase.py.orig
/usr/local/lib/python2.2/markupbase.py
--- /usr/local/lib/python2.2/markupbase.py.orig Mon Mar
17 09:23:17 2003
+++ /usr/local/lib/python2.2/markupbase.py      Mon Mar
17 09:26:45 2003
@@ -3,7 +3,8 @@
 import re
 import string

-_declname_match =
re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*').match
+#_declname_match =
re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*').match  # was this
+_declname_match =
re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*|\[.*\]').match
# replace by this
 _declstringlit_match =
re.compile(r'(\'[^\']*\'|"[^"]*")\s*').match

 del re
@@ -73,7 +74,7 @@
             if c == ">":
                 # end of declaration syntax
                 data = rawdata[i+2:j]
-                if decltype == "doctype":
+                if decltype == "doctype" or
decltype[0] == '[':        # handle 
                     self.handle_decl(data)
                 else:
                     self.unknown_decl(data)
@@ -310,7 +311,7 @@
             return string.lower(name), m.end()
         else:
             self.updatepos(declstartpos, i)
-            self.error("expected name token")
+            self.error("expected name token '%s'" %
rawdata[i:i+10]) # improve error message

     # To be overridden -- handlers for unknown objects
     def unknown_decl(self, data):

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704996&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 18:06:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 10:06:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-704919 ] Problems building python with tkinter on HPUX...
Message-ID: 

Bugs item #704919, was opened at 2003-03-17 12:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jayce Piel (jayce)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems building python with tkinter on HPUX...

Initial Comment:
I have some problems when trying to install python on a
HPUX 10.20 system.
All seems to go well during the compiling and during
the installation process, but when I try to use tkinter
in my new python with an "import _tkinter", i have the
following lines :
Python 2.2.2 (#2, Mar 17 2003, 04:36:02)
[GCC 2.95.2 19991024 (release)] on hp-ux10
Type "help", "copyright", "credits" or "license" for
more information.
>>> import _tkinter
/usr/lib/dld.sl: Unresolved symbol: acos (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: asin (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: atan (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: cosh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: log10 (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: sinh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: tan (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved symbol: tanh (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclTraceExec (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclProcBodyType (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclFreeObjList (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
tclExecutableName (data)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
/usr/lib/dld.sl: Unresolved module for symbol:
Tcl_FindExecutable (code)  from
/usr/local/lib/python2.2/lib-dynload/_tkinter.sl
zsh: abort (core dumped)  python

I have a python1.5/tkinter that works with tcl/tk 8.0p2...
When trying to compile with this version of tcl/tk, i
had errors with the tkinter module compilation.
Then, I tried to compile a tcl/tk 8.4.2, or even use a
binary-package of a tcl/tk 8.2.1, but in both cases I
have the above errors when running...




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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:06

Message:
Logged In: YES 
user_id=21627

This modification cannot go into the CVS: Hard-coding the
path for egcs is not acceptable.

Are you interested in developing a proper patch, or are you
satisfied with the solution that works for you?

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

Comment By: Jayce Piel (jayce)
Date: 2003-03-21 15:51

Message:
Logged In: YES 
user_id=5496

OK, all works now...
Here are what I need to modify :
In the Makefile of tcl 8.4.2 and in the Makefile of tk 8.4.2 :
SHLIB_LD                = gcc -shared -fPIC
LD_SEARCH_FLAGS =

In the Makefile of Python :
LDSHARED=       ld -b -L/usr/lib -lm
-L/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91
.60 -lgcc
BLDSHARED=      ld -b -L/usr/lib -lm
-L/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91
.60 -lgcc


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

Comment By: Jayce Piel (jayce)
Date: 2003-03-21 14:37

Message:
Logged In: YES 
user_id=5496

After different tries, I found that adding "-L/usr/lib -lm"
as parameters of "ld -b" solved THIS problem...

But I still have a problem... Now, when laucnhing
Tkinter._test(), I have the error message  :
"/usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code)  from
/usr/local/lib/libtcl8.4.sl"
And a core dumped...
I have compiled tcl/tk without threads, and python without
threads too...


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:48

Message:
Logged In: YES 
user_id=33168

The problem appears to be that -lm (ie the math library)
needs to be linked, but is not.  I do not have access to a
10.20 machine.  It also looks like the tcl library may not
be found.  Perhaps there's a library search problem?  Jayce,
if you could produce a patch that works for you, I can check
in a fix.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704919&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 18:16:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 10:16:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 21:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Jason Tishler (jlt63)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 04:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-19 04:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 18:22:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 10:22:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx)
Message-ID: 

Bugs item #704180, was opened at 2003-03-15 17:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470

Category: Threads
Group: Python 2.2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak: threading.Thread.__init__(self, target=self.xx)

Initial Comment:
This call  
	threading.Thread.__init__(self, target=self.xxx) 
makes this assignment  
	self.__target = target 
Which looks like a circular refrence to me.  
weakref anyone ? 
 
The following test code shows the leak in action. 
 
--Darrell 
 
 
import threading, time 
 
class T1(threading.Thread): 
    def __init__(self, leak=0): 
        self.leak=leak 
        if leak: 
            threading.Thread.__init__(self, target=self.m1) 
        else: 
            threading.Thread.__init__(self) 
        self.start() 
         
    def run(self): 
        pass 
         
    def m1(self): 
        pass 
         
    def __del__(self): 
        print 'DEL:', self, "leak:",self.leak 
         
 
for x in range(10): 
    T1(leak=1) 
for x in range(10): 
    T1() 
time.sleep(1) 
 
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:22

Message:
Logged In: YES 
user_id=21627

I fail to see a bug in Python here. You are passing a
reference to an object to the __init__ of the base class, so
you should know you are creating cycles.

I recommend to re-implement T1.run instead of using the
target= constructor argument.

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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-16 17:45

Message:
Logged In: YES 
user_id=68151

I know about the __del__ issue with gc, and your right this example worked 
fine with it removed. The much larger app that sent me on this chase wasn't 
fixed by the __del__ method. Yet it was fixed by moving the target method 
to a function call instead of a method on the object. 
 
It's a large app and the timing of when an object is destroyed matters. 
The following helps me see my problem.  
 
import threading, time, weakref 
 
class T1(threading.Thread): 
    def __init__(self): 
        self.go=1 
        threading.Thread.__init__(self, target=self.m1) 
        self.start() 
         
    def m1(self): 
        while self.go: 
            time.sleep(0.0001) 
         
 
objs={} 
while 1: 
    t1 = weakref.ref(T1()) 
    objs[t1]=1 
    t1().go=0 
    time.sleep(0.01) 
    for o in objs.keys(): 
        if o() == None: 
            del objs[o] 
    print len(objs), 
 
 
         
 
 
 

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-16 05:39

Message:
Logged In: YES 
user_id=31435

The "leak" is due to that you gave this class a __del__ 
method:  cyclic garbage collection won't magically reclaim 
objects in cycles with __del__ methods.  Remove the 
__del__ and you can run this all day without the process 
size growing.  If you leave the __del__ in, you can find all 
your uncollectible thread objects in gc.garbage (and use 
that to break the cycles and get them collected, if you like --
 I'd recommend not using __del__ at all, though).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 18:24:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 10:24:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-704174 ] Memory leak: threading.Thread.__init__(self, target=self.xx)
Message-ID: 

Bugs item #704174, was opened at 2003-03-15 17:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704174&group_id=5470

Category: Threads
Group: Python 2.2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak: threading.Thread.__init__(self, target=self.xx)

Initial Comment:
This call  
	threading.Thread.__init__(self, target=self.xxx) 
makes this assignment  
	self.__target = target 
Which looks like a circular refrence to me.  
weakref anyone ? 
 
The following test code shows the leak in action. 
 
--Darrell 
 
 
import threading, time 
 
class T1(threading.Thread): 
    def __init__(self, leak=0): 
        self.leak=leak 
        if leak: 
            threading.Thread.__init__(self, target=self.m1) 
        else: 
            threading.Thread.__init__(self) 
        self.start() 
         
    def run(self): 
        pass 
         
    def m1(self): 
        pass 
         
    def __del__(self): 
        print 'DEL:', self, "leak:",self.leak 
         
 
for x in range(10): 
    T1(leak=1) 
for x in range(10): 
    T1() 
time.sleep(1) 
 
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:24

Message:
Logged In: YES 
user_id=21627

Duplicate of 704180.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704174&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 19:41:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 11:41:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-707707 ] elisp: IM-python menu and newline in function defs
Message-ID: 

Bugs item #707707, was opened at 2003-03-21 19:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707707&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: elisp: IM-python menu and newline in function defs

Initial Comment:
[ forwarded from http://bugs.debian.org/182297 ]

the IM-Python menu does not show a function like this:

def editor(db, db_name, table_name,
           #api
	   dbapi,dbapi_exceptions):



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707707&group_id=5470


From noreply@sourceforge.net  Fri Mar 21 20:03:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 21 Mar 2003 12:03:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-707707 ] elisp: IM-python menu and newline in function defs
Message-ID: 

Bugs item #707707, was opened at 2003-03-21 14:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707707&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: elisp: IM-python menu and newline in function defs

Initial Comment:
[ forwarded from http://bugs.debian.org/182297 ]

the IM-Python menu does not show a function like this:

def editor(db, db_name, table_name,
           #api
	   dbapi,dbapi_exceptions):



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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-21 15:03

Message:
Logged In: YES 
user_id=12800

assigning to myself although i don't know when i'll have
time for python-mode stuff again

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707707&group_id=5470


From noreply@sourceforge.net  Sat Mar 22 20:05:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 12:05:42 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase
Message-ID: 

Feature Requests item #708125, was opened at 2003-03-22 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Russell (mattruss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Requesting Mock Object support for unittest.TestCase

Initial Comment:
I previously submitted a patch (sf id 706590),
since I was following www.python.com's notes on how 
to contribute - since using sf more i think i should of 
added it to this RFE. Since posting the orignal patch I 
have updated the code based upon sugestions from 
python-dev and others.

please view my origanal patch here:
https://sourceforge.net/tracker/index.php?
func=detail&aid=706590&group_id=5470&atid=305470

This patch adds one method - createMockInstance
(classDef, overrides, *initArgs, **initKwds)
to unittest.TestCase, and two classes MockFactory and 
MockMethod.

Since both these classes should never really be used 
outside the scope of a unittest, I thought it best to add 
them to the unittest module (allthough it is getting rather 
big - should be split into a package?)




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470


From noreply@sourceforge.net  Sat Mar 22 20:36:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 12:36:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx)
Message-ID: 

Bugs item #704180, was opened at 2003-03-15 16:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak: threading.Thread.__init__(self, target=self.xx)

Initial Comment:
This call  
	threading.Thread.__init__(self, target=self.xxx) 
makes this assignment  
	self.__target = target 
Which looks like a circular refrence to me.  
weakref anyone ? 
 
The following test code shows the leak in action. 
 
--Darrell 
 
 
import threading, time 
 
class T1(threading.Thread): 
    def __init__(self, leak=0): 
        self.leak=leak 
        if leak: 
            threading.Thread.__init__(self, target=self.m1) 
        else: 
            threading.Thread.__init__(self) 
        self.start() 
         
    def run(self): 
        pass 
         
    def m1(self): 
        pass 
         
    def __del__(self): 
        print 'DEL:', self, "leak:",self.leak 
         
 
for x in range(10): 
    T1(leak=1) 
for x in range(10): 
    T1() 
time.sleep(1) 
 
 

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

>Comment By: Darrell Gallion (dgallion)
Date: 2003-03-22 20:36

Message:
Logged In: YES 
user_id=68151

Using a threading.Thread as a base class invites you to pass target methods 
other than run. Which sets up the cycle. It would be nice if the target could 
be a weakref or was converted to a weakref by Thread. 
 
This simple change would prevent others from wasting time on this problem. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 18:22

Message:
Logged In: YES 
user_id=21627

I fail to see a bug in Python here. You are passing a
reference to an object to the __init__ of the base class, so
you should know you are creating cycles.

I recommend to re-implement T1.run instead of using the
target= constructor argument.

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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-16 16:45

Message:
Logged In: YES 
user_id=68151

I know about the __del__ issue with gc, and your right this example worked 
fine with it removed. The much larger app that sent me on this chase wasn't 
fixed by the __del__ method. Yet it was fixed by moving the target method 
to a function call instead of a method on the object. 
 
It's a large app and the timing of when an object is destroyed matters. 
The following helps me see my problem.  
 
import threading, time, weakref 
 
class T1(threading.Thread): 
    def __init__(self): 
        self.go=1 
        threading.Thread.__init__(self, target=self.m1) 
        self.start() 
         
    def m1(self): 
        while self.go: 
            time.sleep(0.0001) 
         
 
objs={} 
while 1: 
    t1 = weakref.ref(T1()) 
    objs[t1]=1 
    t1().go=0 
    time.sleep(0.01) 
    for o in objs.keys(): 
        if o() == None: 
            del objs[o] 
    print len(objs), 
 
 
         
 
 
 

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-16 04:39

Message:
Logged In: YES 
user_id=31435

The "leak" is due to that you gave this class a __del__ 
method:  cyclic garbage collection won't magically reclaim 
objects in cycles with __del__ methods.  Remove the 
__del__ and you can run this all day without the process 
size growing.  If you leave the __del__ in, you can find all 
your uncollectible thread objects in gc.garbage (and use 
that to break the cycles and get them collected, if you like --
 I'd recommend not using __del__ at all, though).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470


From noreply@sourceforge.net  Sat Mar 22 21:30:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 13:30:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx)
Message-ID: 

Bugs item #704180, was opened at 2003-03-15 17:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak: threading.Thread.__init__(self, target=self.xx)

Initial Comment:
This call  
	threading.Thread.__init__(self, target=self.xxx) 
makes this assignment  
	self.__target = target 
Which looks like a circular refrence to me.  
weakref anyone ? 
 
The following test code shows the leak in action. 
 
--Darrell 
 
 
import threading, time 
 
class T1(threading.Thread): 
    def __init__(self, leak=0): 
        self.leak=leak 
        if leak: 
            threading.Thread.__init__(self, target=self.m1) 
        else: 
            threading.Thread.__init__(self) 
        self.start() 
         
    def run(self): 
        pass 
         
    def m1(self): 
        pass 
         
    def __del__(self): 
        print 'DEL:', self, "leak:",self.leak 
         
 
for x in range(10): 
    T1(leak=1) 
for x in range(10): 
    T1() 
time.sleep(1) 
 
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-22 22:30

Message:
Logged In: YES 
user_id=21627

That won't work. In your example, the method object is
created with the expression self.m1, and the only reference
to it is the target parameter. So if Thread would keep just
a weak reference to target, then the method object would go
away just after __init__ completes. As the result, the
Thread's .run won't find the target.


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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-22 21:36

Message:
Logged In: YES 
user_id=68151

Using a threading.Thread as a base class invites you to pass target methods 
other than run. Which sets up the cycle. It would be nice if the target could 
be a weakref or was converted to a weakref by Thread. 
 
This simple change would prevent others from wasting time on this problem. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:22

Message:
Logged In: YES 
user_id=21627

I fail to see a bug in Python here. You are passing a
reference to an object to the __init__ of the base class, so
you should know you are creating cycles.

I recommend to re-implement T1.run instead of using the
target= constructor argument.

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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-16 17:45

Message:
Logged In: YES 
user_id=68151

I know about the __del__ issue with gc, and your right this example worked 
fine with it removed. The much larger app that sent me on this chase wasn't 
fixed by the __del__ method. Yet it was fixed by moving the target method 
to a function call instead of a method on the object. 
 
It's a large app and the timing of when an object is destroyed matters. 
The following helps me see my problem.  
 
import threading, time, weakref 
 
class T1(threading.Thread): 
    def __init__(self): 
        self.go=1 
        threading.Thread.__init__(self, target=self.m1) 
        self.start() 
         
    def m1(self): 
        while self.go: 
            time.sleep(0.0001) 
         
 
objs={} 
while 1: 
    t1 = weakref.ref(T1()) 
    objs[t1]=1 
    t1().go=0 
    time.sleep(0.01) 
    for o in objs.keys(): 
        if o() == None: 
            del objs[o] 
    print len(objs), 
 
 
         
 
 
 

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-16 05:39

Message:
Logged In: YES 
user_id=31435

The "leak" is due to that you gave this class a __del__ 
method:  cyclic garbage collection won't magically reclaim 
objects in cycles with __del__ methods.  Remove the 
__del__ and you can run this all day without the process 
size growing.  If you leave the __del__ in, you can find all 
your uncollectible thread objects in gc.garbage (and use 
that to break the cycles and get them collected, if you like --
 I'd recommend not using __del__ at all, though).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470


From noreply@sourceforge.net  Sat Mar 22 22:45:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 14:45:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx)
Message-ID: 

Bugs item #704180, was opened at 2003-03-15 11:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak: threading.Thread.__init__(self, target=self.xx)

Initial Comment:
This call  
	threading.Thread.__init__(self, target=self.xxx) 
makes this assignment  
	self.__target = target 
Which looks like a circular refrence to me.  
weakref anyone ? 
 
The following test code shows the leak in action. 
 
--Darrell 
 
 
import threading, time 
 
class T1(threading.Thread): 
    def __init__(self, leak=0): 
        self.leak=leak 
        if leak: 
            threading.Thread.__init__(self, target=self.m1) 
        else: 
            threading.Thread.__init__(self) 
        self.start() 
         
    def run(self): 
        pass 
         
    def m1(self): 
        pass 
         
    def __del__(self): 
        print 'DEL:', self, "leak:",self.leak 
         
 
for x in range(10): 
    T1(leak=1) 
for x in range(10): 
    T1() 
time.sleep(1) 
 
 

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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-22 17:45

Message:
Logged In: YES 
user_id=31435

As Martin said, a weakref won't solve anything here.

I remain unclear on what the real problem is.  You said that 
the timing of when an object gets destroyed is important to 
your app, but you have to realize that Python makes no 
guarantees about object destruction time.  If your thread is 
holding on to some critical resource that must be freed in a 
timely manner, the only sane way to proceed is to give your 
thread a release() or close() method that's called explicitly 
to free the critical resource.  That should never be left to 
the vagaries of garbage collection (whether via refcount or 
the gc module).

BTW, I don't believe I've ever seen code that passed a 
bound method of a Thread subclass to Thread.__init__ 
before.  The target argument was meant to ease migrating 
old code that used the thread module (where specifying a 
target function was necessary).  Code written with 
threading.py in mind invariably (IME) overrides the run() 
method instead (which is the intent of the design).

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-22 16:30

Message:
Logged In: YES 
user_id=21627

That won't work. In your example, the method object is
created with the expression self.m1, and the only reference
to it is the target parameter. So if Thread would keep just
a weak reference to target, then the method object would go
away just after __init__ completes. As the result, the
Thread's .run won't find the target.


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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-22 15:36

Message:
Logged In: YES 
user_id=68151

Using a threading.Thread as a base class invites you to pass target methods 
other than run. Which sets up the cycle. It would be nice if the target could 
be a weakref or was converted to a weakref by Thread. 
 
This simple change would prevent others from wasting time on this problem. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 13:22

Message:
Logged In: YES 
user_id=21627

I fail to see a bug in Python here. You are passing a
reference to an object to the __init__ of the base class, so
you should know you are creating cycles.

I recommend to re-implement T1.run instead of using the
target= constructor argument.

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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-16 11:45

Message:
Logged In: YES 
user_id=68151

I know about the __del__ issue with gc, and your right this example worked 
fine with it removed. The much larger app that sent me on this chase wasn't 
fixed by the __del__ method. Yet it was fixed by moving the target method 
to a function call instead of a method on the object. 
 
It's a large app and the timing of when an object is destroyed matters. 
The following helps me see my problem.  
 
import threading, time, weakref 
 
class T1(threading.Thread): 
    def __init__(self): 
        self.go=1 
        threading.Thread.__init__(self, target=self.m1) 
        self.start() 
         
    def m1(self): 
        while self.go: 
            time.sleep(0.0001) 
         
 
objs={} 
while 1: 
    t1 = weakref.ref(T1()) 
    objs[t1]=1 
    t1().go=0 
    time.sleep(0.01) 
    for o in objs.keys(): 
        if o() == None: 
            del objs[o] 
    print len(objs), 
 
 
         
 
 
 

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-15 23:39

Message:
Logged In: YES 
user_id=31435

The "leak" is due to that you gave this class a __del__ 
method:  cyclic garbage collection won't magically reclaim 
objects in cycles with __del__ methods.  Remove the 
__del__ and you can run this all day without the process 
size growing.  If you leave the __del__ in, you can find all 
your uncollectible thread objects in gc.garbage (and use 
that to break the cycles and get them collected, if you like --
 I'd recommend not using __del__ at all, though).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470


From noreply@sourceforge.net  Sat Mar 22 23:39:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 15:39:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-708194 ] unbalanced parentheses for lists
Message-ID: 

Bugs item #708194, was opened at 2003-03-22 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Ross Boylan (rboylan)
Assigned to: Nobody/Anonymous (nobody)
Summary: unbalanced parentheses for lists

Initial Comment:
Section 5.2.4, list displays, includes this line:
listmaker   ::=   expression ( list_for  | ( ","
expression)* [","] )

Doesn't that need another ")" somewhere?

My documentation says 
Python Reference Manual, July 29, 2002, Release 2.2.1+

It's on a Debian testing system.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 00:26:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 16:26:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-708194 ] unbalanced parentheses for lists
Message-ID: 

Bugs item #708194, was opened at 2003-03-22 18:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Ross Boylan (rboylan)
Assigned to: Nobody/Anonymous (nobody)
Summary: unbalanced parentheses for lists

Initial Comment:
Section 5.2.4, list displays, includes this line:
listmaker   ::=   expression ( list_for  | ( ","
expression)* [","] )

Doesn't that need another ")" somewhere?

My documentation says 
Python Reference Manual, July 29, 2002, Release 2.2.1+

It's on a Debian testing system.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-22 19:26

Message:
Logged In: YES 
user_id=33168

I fail to see the problem.  There are two ( and two ). 
Perhaps, you are confused since the ) immediately follows
expression without a space?  Is the following clearer?

  expression ( list_for | ( "," expression )* [","] ) 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 00:26:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 16:26:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-708205 ] math.fabs documentation is misleading
Message-ID: 

Bugs item #708205, was opened at 2003-03-23 09:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: math.fabs documentation is misleading

Initial Comment:
math.fabs documentation is misleading.
It says,
"Return the absolute value of the floating point number 
x. ".
but I think it should look like this:
"Return the absolute value of x as a float."

See the code below.

>>> from math import *
>>> abs(3)
3
>>> fabs(3)
3.0

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708205&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 02:05:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 18:05:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-708194 ] unbalanced parentheses for lists
Message-ID: 

Bugs item #708194, was opened at 2003-03-22 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Ross Boylan (rboylan)
Assigned to: Nobody/Anonymous (nobody)
Summary: unbalanced parentheses for lists

Initial Comment:
Section 5.2.4, list displays, includes this line:
listmaker   ::=   expression ( list_for  | ( ","
expression)* [","] )

Doesn't that need another ")" somewhere?

My documentation says 
Python Reference Manual, July 29, 2002, Release 2.2.1+

It's on a Debian testing system.


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

>Comment By: Ross Boylan (rboylan)
Date: 2003-03-22 18:05

Message:
Logged In: YES 
user_id=300987

I don't know what I was thinking.  It's fine.  You can close
this.  Sorry.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-22 16:26

Message:
Logged In: YES 
user_id=33168

I fail to see the problem.  There are two ( and two ). 
Perhaps, you are confused since the ) immediately follows
expression without a space?  Is the following clearer?

  expression ( list_for | ( "," expression )* [","] ) 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 02:50:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 22 Mar 2003 18:50:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-708194 ] unbalanced parentheses for lists
Message-ID: 

Bugs item #708194, was opened at 2003-03-22 18:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ross Boylan (rboylan)
Assigned to: Nobody/Anonymous (nobody)
Summary: unbalanced parentheses for lists

Initial Comment:
Section 5.2.4, list displays, includes this line:
listmaker   ::=   expression ( list_for  | ( ","
expression)* [","] )

Doesn't that need another ")" somewhere?

My documentation says 
Python Reference Manual, July 29, 2002, Release 2.2.1+

It's on a Debian testing system.


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

Comment By: Ross Boylan (rboylan)
Date: 2003-03-22 21:05

Message:
Logged In: YES 
user_id=300987

I don't know what I was thinking.  It's fine.  You can close
this.  Sorry.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-22 19:26

Message:
Logged In: YES 
user_id=33168

I fail to see the problem.  There are two ( and two ). 
Perhaps, you are confused since the ) immediately follows
expression without a space?  Is the following clearer?

  expression ( list_for | ( "," expression )* [","] ) 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708194&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 10:52:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 02:52:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-708320 ] DistributionMetaData error ?
Message-ID: 

Bugs item #708320, was opened at 2003-03-23 11:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708320&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Cédric Dutoit (dutoitc)
Assigned to: Nobody/Anonymous (nobody)
Summary: DistributionMetaData error ?

Initial Comment:
I'm trying to create an .exe from python files and got the 
following errors :

--------------------------------------------------------------------------------
L:\build\gimini\giminiV15-2-exe\src>c:\python22\python 
setup.py py2exe
Traceback (most recent call last):
  File "setup.py", line 8, in ?
    data_files=[   (   "img",
  File "C:\PYTHON22\distutils\core.py", line 101, in setup
    _setup_distribution = dist = klass(attrs)
  File "C:\PYTHON22\distutils\dist.py", line 130, in 
__init__
    setattr(self, method_name, getattr(self.metadata, 
method_name))
AttributeError: DistributionMetadata instance has no 
attribute 'get___doc__'
--------------------------------------------------------------------------------

C.Dutoit

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708320&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 13:52:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 05:52:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-704180 ] Memory leak: threading.Thread.__init__(self, target=self.xx)
Message-ID: 

Bugs item #704180, was opened at 2003-03-15 16:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak: threading.Thread.__init__(self, target=self.xx)

Initial Comment:
This call  
	threading.Thread.__init__(self, target=self.xxx) 
makes this assignment  
	self.__target = target 
Which looks like a circular refrence to me.  
weakref anyone ? 
 
The following test code shows the leak in action. 
 
--Darrell 
 
 
import threading, time 
 
class T1(threading.Thread): 
    def __init__(self, leak=0): 
        self.leak=leak 
        if leak: 
            threading.Thread.__init__(self, target=self.m1) 
        else: 
            threading.Thread.__init__(self) 
        self.start() 
         
    def run(self): 
        pass 
         
    def m1(self): 
        pass 
         
    def __del__(self): 
        print 'DEL:', self, "leak:",self.leak 
         
 
for x in range(10): 
    T1(leak=1) 
for x in range(10): 
    T1() 
time.sleep(1) 
 
 

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

>Comment By: Darrell Gallion (dgallion)
Date: 2003-03-23 13:52

Message:
Logged In: YES 
user_id=68151

My problem was solved by moving the thread options into a group of 
functions and passing one of those as the target. These threads have a 
shutDown method that didn't work before because of this target problem.  
 
This isn't a problem for me now, yet it seemed like it could have been 
avoided in the first place.  
 
Thanks 

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-22 22:45

Message:
Logged In: YES 
user_id=31435

As Martin said, a weakref won't solve anything here.

I remain unclear on what the real problem is.  You said that 
the timing of when an object gets destroyed is important to 
your app, but you have to realize that Python makes no 
guarantees about object destruction time.  If your thread is 
holding on to some critical resource that must be freed in a 
timely manner, the only sane way to proceed is to give your 
thread a release() or close() method that's called explicitly 
to free the critical resource.  That should never be left to 
the vagaries of garbage collection (whether via refcount or 
the gc module).

BTW, I don't believe I've ever seen code that passed a 
bound method of a Thread subclass to Thread.__init__ 
before.  The target argument was meant to ease migrating 
old code that used the thread module (where specifying a 
target function was necessary).  Code written with 
threading.py in mind invariably (IME) overrides the run() 
method instead (which is the intent of the design).

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-22 21:30

Message:
Logged In: YES 
user_id=21627

That won't work. In your example, the method object is
created with the expression self.m1, and the only reference
to it is the target parameter. So if Thread would keep just
a weak reference to target, then the method object would go
away just after __init__ completes. As the result, the
Thread's .run won't find the target.


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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-22 20:36

Message:
Logged In: YES 
user_id=68151

Using a threading.Thread as a base class invites you to pass target methods 
other than run. Which sets up the cycle. It would be nice if the target could 
be a weakref or was converted to a weakref by Thread. 
 
This simple change would prevent others from wasting time on this problem. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 18:22

Message:
Logged In: YES 
user_id=21627

I fail to see a bug in Python here. You are passing a
reference to an object to the __init__ of the base class, so
you should know you are creating cycles.

I recommend to re-implement T1.run instead of using the
target= constructor argument.

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

Comment By: Darrell Gallion (dgallion)
Date: 2003-03-16 16:45

Message:
Logged In: YES 
user_id=68151

I know about the __del__ issue with gc, and your right this example worked 
fine with it removed. The much larger app that sent me on this chase wasn't 
fixed by the __del__ method. Yet it was fixed by moving the target method 
to a function call instead of a method on the object. 
 
It's a large app and the timing of when an object is destroyed matters. 
The following helps me see my problem.  
 
import threading, time, weakref 
 
class T1(threading.Thread): 
    def __init__(self): 
        self.go=1 
        threading.Thread.__init__(self, target=self.m1) 
        self.start() 
         
    def m1(self): 
        while self.go: 
            time.sleep(0.0001) 
         
 
objs={} 
while 1: 
    t1 = weakref.ref(T1()) 
    objs[t1]=1 
    t1().go=0 
    time.sleep(0.01) 
    for o in objs.keys(): 
        if o() == None: 
            del objs[o] 
    print len(objs), 
 
 
         
 
 
 

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-16 04:39

Message:
Logged In: YES 
user_id=31435

The "leak" is due to that you gave this class a __del__ 
method:  cyclic garbage collection won't magically reclaim 
objects in cycles with __del__ methods.  Remove the 
__del__ and you can run this all day without the process 
size growing.  If you leave the __del__ in, you can find all 
your uncollectible thread objects in gc.garbage (and use 
that to break the cycles and get them collected, if you like --
 I'd recommend not using __del__ at all, though).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704180&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 14:56:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 06:56:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-698517 ] Tk 8.4.2 and Tkinter.py _substitue function
Message-ID: 

Bugs item #698517, was opened at 2003-03-06 06:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698517&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
>Assigned to: Martin v. Löwis (loewis)
Summary: Tk 8.4.2 and Tkinter.py _substitue function

Initial Comment:
In Tk 8.4.2 (out now, or RSN), a change was made to events. From Tk's ChangeLog:

        * generic/tkBind.c (ExpandPercents): Only allow events to see
        those expansions that are actually valid for them, and force the
        substitution of the rest as "??".  This stops some crashes on
        Windows and gets rid of bogus values everywhere.  [Bug #612110]

Thus, Tkinter.py's _substitue method of Class Misc will need all of it's called to getint() (aka int()) wrapped to catch ValueErrors because the argument could now be '??' instead of something int()'able.

Does that make sense?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698517&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 15:40:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 07:40:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-708320 ] DistributionMetaData error ?
Message-ID: 

Bugs item #708320, was opened at 2003-03-23 05:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708320&group_id=5470

Category: Distutils
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Cédric Dutoit (dutoitc)
>Assigned to: Thomas Heller (theller)
Summary: DistributionMetaData error ?

Initial Comment:
I'm trying to create an .exe from python files and got the 
following errors :

--------------------------------------------------------------------------------
L:\build\gimini\giminiV15-2-exe\src>c:\python22\python 
setup.py py2exe
Traceback (most recent call last):
  File "setup.py", line 8, in ?
    data_files=[   (   "img",
  File "C:\PYTHON22\distutils\core.py", line 101, in setup
    _setup_distribution = dist = klass(attrs)
  File "C:\PYTHON22\distutils\dist.py", line 130, in 
__init__
    setattr(self, method_name, getattr(self.metadata, 
method_name))
AttributeError: DistributionMetadata instance has no 
attribute 'get___doc__'
--------------------------------------------------------------------------------

C.Dutoit

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:40

Message:
Logged In: YES 
user_id=33168

Is this a bug in python or in py2exe?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708320&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 15:48:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 07:48:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 10:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 12:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 17:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 04:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 12:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-27 22:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 15:52:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 07:52:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 10:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:52

Message:
Logged In: YES 
user_id=33168

Looking further into the python configure, I see that the
option is --with-dl-dld, however, this option is not
supported.  Can try to play with the build options to find
the magic that works on your version of HPUX?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 12:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 17:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 04:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 12:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-27 22:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 15:59:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 07:59:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError
Message-ID: 

Bugs item #697591, was opened at 2003-03-04 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Murff (jmurff)
>Assigned to: Martin v. Löwis (loewis)
Summary: string.atoi function causing TypeError

Initial Comment:
Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:59

Message:
Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

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

Comment By: John Speno (corvus)
Date: 2003-03-18 21:57

Message:
Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 20:24

Message:
Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 13:12

Message:
Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

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

Comment By: John Speno (corvus)
Date: 2003-03-12 11:14

Message:
Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 17:39

Message:
Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 16:57

Message:
Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.


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

Comment By: John Speno (corvus)
Date: 2003-03-05 15:43

Message:
Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 14:40

Message:
Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 



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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 13:49

Message:
Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-04 21:18

Message:
Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

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

Comment By: John Speno (corvus)
Date: 2003-03-04 20:50

Message:
Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 17:48:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 09:48:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-708320 ] DistributionMetaData error ?
Message-ID: 

Bugs item #708320, was opened at 2003-03-23 11:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708320&group_id=5470

Category: Distutils
Group: Python 2.2.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Cédric Dutoit (dutoitc)
Assigned to: Thomas Heller (theller)
Summary: DistributionMetaData error ?

Initial Comment:
I'm trying to create an .exe from python files and got the 
following errors :

--------------------------------------------------------------------------------
L:\build\gimini\giminiV15-2-exe\src>c:\python22\python 
setup.py py2exe
Traceback (most recent call last):
  File "setup.py", line 8, in ?
    data_files=[   (   "img",
  File "C:\PYTHON22\distutils\core.py", line 101, in setup
    _setup_distribution = dist = klass(attrs)
  File "C:\PYTHON22\distutils\dist.py", line 130, in 
__init__
    setattr(self, method_name, getattr(self.metadata, 
method_name))
AttributeError: DistributionMetadata instance has no 
attribute 'get___doc__'
--------------------------------------------------------------------------------

C.Dutoit

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

>Comment By: Cédric Dutoit (dutoitc)
Date: 2003-03-23 18:48

Message:
Logged In: YES 
user_id=64541

This seems to be a problem of version. I installed the latest 
version and it is ok.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 16:40

Message:
Logged In: YES 
user_id=33168

Is this a bug in python or in py2exe?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708320&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 18:02:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 10:02:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError
Message-ID: 

Bugs item #697591, was opened at 2003-03-04 23:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Murff (jmurff)
Assigned to: Martin v. Löwis (loewis)
Summary: string.atoi function causing TypeError

Initial Comment:
Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 19:02

Message:
Logged In: YES 
user_id=21627

We have to separate issues. There is bug 698517, which is
caused by Tk now (8.4.2) passing the string "??" in places
where it would previously only  pass numbers, and patch
707701, which tries to work around this.

There appears to be an independent issue with Pmw, which I
suggest not to investigate further until somebody can
provide a reproducable test case, in Pmw (preferably
indicating the precise Pmw version).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 16:59

Message:
Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 03:57

Message:
Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 02:24

Message:
Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 19:12

Message:
Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

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

Comment By: John Speno (corvus)
Date: 2003-03-12 17:14

Message:
Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 23:39

Message:
Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 22:57

Message:
Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.


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

Comment By: John Speno (corvus)
Date: 2003-03-05 21:43

Message:
Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 20:40

Message:
Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 



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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 19:49

Message:
Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 03:18

Message:
Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

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

Comment By: John Speno (corvus)
Date: 2003-03-05 02:50

Message:
Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 19:36:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 11:36:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError
Message-ID: 

Bugs item #697591, was opened at 2003-03-04 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Murff (jmurff)
Assigned to: Martin v. Löwis (loewis)
Summary: string.atoi function causing TypeError

Initial Comment:
Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

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

Comment By: John Speno (corvus)
Date: 2003-03-23 14:36

Message:
Logged In: YES 
user_id=2138

This isn't a Pmw issue. I just built Python 2.2.2 with Tcl/Tk 8.4.1 and Python 2.3 with the same Tcl/Tk. This code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a)

produces these results:

On python 2.2.2: 
        

On python 2.3:
        

So, there you have it. Python 2.3a2's tkinter isn't backwards compatable with 2.2.

I don't know if that's a problem or not. It's just an observation I came across while porting some older python code (which used Pmw) to 2.3.

Hope that helps!

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 13:02

Message:
Logged In: YES 
user_id=21627

We have to separate issues. There is bug 698517, which is
caused by Tk now (8.4.2) passing the string "??" in places
where it would previously only  pass numbers, and patch
707701, which tries to work around this.

There appears to be an independent issue with Pmw, which I
suggest not to investigate further until somebody can
provide a reproducable test case, in Pmw (preferably
indicating the precise Pmw version).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:59

Message:
Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

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

Comment By: John Speno (corvus)
Date: 2003-03-18 21:57

Message:
Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 20:24

Message:
Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 13:12

Message:
Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

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

Comment By: John Speno (corvus)
Date: 2003-03-12 11:14

Message:
Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 17:39

Message:
Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 16:57

Message:
Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.


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

Comment By: John Speno (corvus)
Date: 2003-03-05 15:43

Message:
Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 14:40

Message:
Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 



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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 13:49

Message:
Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-04 21:18

Message:
Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

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

Comment By: John Speno (corvus)
Date: 2003-03-04 20:50

Message:
Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 20:27:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 12:27:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError
Message-ID: 

Bugs item #697591, was opened at 2003-03-04 23:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Murff (jmurff)
Assigned to: Martin v. Löwis (loewis)
Summary: string.atoi function causing TypeError

Initial Comment:
Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 21:27

Message:
Logged In: YES 
user_id=21627

Yes, the return type of some data changes, and yes, this is
not fully backwards compatible. But this is not a bug, but a
feature, see

http://www.python.org/doc/2.3a2/whatsnew/node16.html

In Tk, borderwidth *is* an integer, not a string.

Applications that cannot accept this change need to write

Tkinter.wantobjects=0

before creating the first tkapp object.

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

Comment By: John Speno (corvus)
Date: 2003-03-23 20:36

Message:
Logged In: YES 
user_id=2138

This isn't a Pmw issue. I just built Python 2.2.2 with Tcl/Tk 8.4.1 and Python 2.3 with the same Tcl/Tk. This code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a)

produces these results:

On python 2.2.2: 
        

On python 2.3:
        

So, there you have it. Python 2.3a2's tkinter isn't backwards compatable with 2.2.

I don't know if that's a problem or not. It's just an observation I came across while porting some older python code (which used Pmw) to 2.3.

Hope that helps!

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 19:02

Message:
Logged In: YES 
user_id=21627

We have to separate issues. There is bug 698517, which is
caused by Tk now (8.4.2) passing the string "??" in places
where it would previously only  pass numbers, and patch
707701, which tries to work around this.

There appears to be an independent issue with Pmw, which I
suggest not to investigate further until somebody can
provide a reproducable test case, in Pmw (preferably
indicating the precise Pmw version).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 16:59

Message:
Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 03:57

Message:
Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 02:24

Message:
Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 19:12

Message:
Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

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

Comment By: John Speno (corvus)
Date: 2003-03-12 17:14

Message:
Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 23:39

Message:
Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 22:57

Message:
Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.


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

Comment By: John Speno (corvus)
Date: 2003-03-05 21:43

Message:
Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 20:40

Message:
Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 



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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 19:49

Message:
Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 03:18

Message:
Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

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

Comment By: John Speno (corvus)
Date: 2003-03-05 02:50

Message:
Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 20:36:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 12:36:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError
Message-ID: 

Bugs item #697591, was opened at 2003-03-04 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Murff (jmurff)
Assigned to: Martin v. Löwis (loewis)
Summary: string.atoi function causing TypeError

Initial Comment:
Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

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

Comment By: John Speno (corvus)
Date: 2003-03-23 15:36

Message:
Logged In: YES 
user_id=2138

Excellent. I think this item should be closed now.

Also, I don't think it has anything to do with bug 698517.

Thanks and take care.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 15:27

Message:
Logged In: YES 
user_id=21627

Yes, the return type of some data changes, and yes, this is
not fully backwards compatible. But this is not a bug, but a
feature, see

http://www.python.org/doc/2.3a2/whatsnew/node16.html

In Tk, borderwidth *is* an integer, not a string.

Applications that cannot accept this change need to write

Tkinter.wantobjects=0

before creating the first tkapp object.

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

Comment By: John Speno (corvus)
Date: 2003-03-23 14:36

Message:
Logged In: YES 
user_id=2138

This isn't a Pmw issue. I just built Python 2.2.2 with Tcl/Tk 8.4.1 and Python 2.3 with the same Tcl/Tk. This code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a)

produces these results:

On python 2.2.2: 
        

On python 2.3:
        

So, there you have it. Python 2.3a2's tkinter isn't backwards compatable with 2.2.

I don't know if that's a problem or not. It's just an observation I came across while porting some older python code (which used Pmw) to 2.3.

Hope that helps!

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 13:02

Message:
Logged In: YES 
user_id=21627

We have to separate issues. There is bug 698517, which is
caused by Tk now (8.4.2) passing the string "??" in places
where it would previously only  pass numbers, and patch
707701, which tries to work around this.

There appears to be an independent issue with Pmw, which I
suggest not to investigate further until somebody can
provide a reproducable test case, in Pmw (preferably
indicating the precise Pmw version).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:59

Message:
Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

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

Comment By: John Speno (corvus)
Date: 2003-03-18 21:57

Message:
Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 20:24

Message:
Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 13:12

Message:
Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

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

Comment By: John Speno (corvus)
Date: 2003-03-12 11:14

Message:
Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 17:39

Message:
Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 16:57

Message:
Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.


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

Comment By: John Speno (corvus)
Date: 2003-03-05 15:43

Message:
Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 14:40

Message:
Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 



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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 13:49

Message:
Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-04 21:18

Message:
Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

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

Comment By: John Speno (corvus)
Date: 2003-03-04 20:50

Message:
Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 20:40:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 12:40:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT
Message-ID: 

Bugs item #663782, was opened at 2003-01-07 10:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470

>Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_socket test_unicode_file fail on 2.3a1 on winNT

Initial Comment:
This happens after installing 2.3a1 on winNT 4 sp6.

D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_socket.py
testCrucialConstants (__main__.GeneralModuleTests) ... ok
testDefaultTimeout (__main__.GeneralModuleTests) ... ok
testGetServByName (__main__.GeneralModuleTests) ... ok
testGetSockOpt (__main__.GeneralModuleTests) ... ok
testHostnameRes (__main__.GeneralModuleTests) ... ok
testInterpreterCrash (__main__.GeneralModuleTests) ... ok
testNtoH (__main__.GeneralModuleTests) ... ok
testRefCountGetNameInfo (__main__.GeneralModuleTests)
... ok
testSendAfterClose (__main__.GeneralModuleTests) ... ok
testSetSockOpt (__main__.GeneralModuleTests) ... ok
testSockName (__main__.GeneralModuleTests) ... ok
testSocketError (__main__.GeneralModuleTests) ... ok
testFromFd (__main__.BasicTCPTest) ... ok
testOverFlowRecv (__main__.BasicTCPTest) ... ok
testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok
testRecv (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicTCPTest) ... ok
testSendAll (__main__.BasicTCPTest) ... ok
testShutdown (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicUDPTest) ... ok
testSendtoAndRecv (__main__.BasicUDPTest) ... ok
testAccept (__main__.NonBlockingTCPTests) ... FAIL
ERROR
testConnect (__main__.NonBlockingTCPTests) ... ok
testRecv (__main__.NonBlockingTCPTests) ... ok
testSetBlocking (__main__.NonBlockingTCPTests) ... ok
testFullRead (__main__.FileObjectClassTestCase) ... ok
testReadline (__main__.FileObjectClassTestCase) ... ok
testSmallRead (__main__.FileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.FileObjectClassTestCase)
... ok
testFullRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok

======================================================================
ERROR: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
117, in _tearDown
    self.fail(msg)
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: (10061, 'Connection refused')

======================================================================
FAIL: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
475, in testAccept
    self.fail("Error trying to do non-blocking accept.")
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: Error trying to do non-blocking accept.

----------------------------------------------------------------------
Ran 42 tests in 2.204s

FAILED (failures=1, errors=1)
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
632, in ?
    test_main()
  File "D:\apps\Python23\Lib\test\test_socket.py", line
629, in test_main
    test_support.run_suite(suite)
  File "D:\apps\Python23\lib\test\test_support.py",
line 217, in run_suite
    raise TestFailed(msg)
test.test_support.TestFailed: errors occurred; run in
verbose mode for details
D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_unicode_file.py
File doesn't exist (encoded string) after creating it
Traceback (most recent call last):
  File
"D:\apps\Python23\Lib\test\test_unicode_file.py", line
37, in ?
    if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE):
OSError: [Errno 2] No such file or directory: '@test-??'


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:40

Message:
Logged In: YES 
user_id=33168

Is this problem still happening with 2.3a2+ ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470


From noreply@sourceforge.net  Sun Mar 23 21:07:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 13:07:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-697591 ] string.atoi function causing TypeError
Message-ID: 

Bugs item #697591, was opened at 2003-03-04 23:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jim Murff (jmurff)
Assigned to: Martin v. Löwis (loewis)
Summary: string.atoi function causing TypeError

Initial Comment:
Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 22:07

Message:
Logged In: YES 
user_id=21627

Ok, closing it - although I'm still curious as to what code
in Pmw broke with that change.

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

Comment By: John Speno (corvus)
Date: 2003-03-23 21:36

Message:
Logged In: YES 
user_id=2138

Excellent. I think this item should be closed now.

Also, I don't think it has anything to do with bug 698517.

Thanks and take care.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 21:27

Message:
Logged In: YES 
user_id=21627

Yes, the return type of some data changes, and yes, this is
not fully backwards compatible. But this is not a bug, but a
feature, see

http://www.python.org/doc/2.3a2/whatsnew/node16.html

In Tk, borderwidth *is* an integer, not a string.

Applications that cannot accept this change need to write

Tkinter.wantobjects=0

before creating the first tkapp object.

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

Comment By: John Speno (corvus)
Date: 2003-03-23 20:36

Message:
Logged In: YES 
user_id=2138

This isn't a Pmw issue. I just built Python 2.2.2 with Tcl/Tk 8.4.1 and Python 2.3 with the same Tcl/Tk. This code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a)

produces these results:

On python 2.2.2: 
        

On python 2.3:
        

So, there you have it. Python 2.3a2's tkinter isn't backwards compatable with 2.2.

I don't know if that's a problem or not. It's just an observation I came across while porting some older python code (which used Pmw) to 2.3.

Hope that helps!

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-23 19:02

Message:
Logged In: YES 
user_id=21627

We have to separate issues. There is bug 698517, which is
caused by Tk now (8.4.2) passing the string "??" in places
where it would previously only  pass numbers, and patch
707701, which tries to work around this.

There appears to be an independent issue with Pmw, which I
suggest not to investigate further until somebody can
provide a reproducable test case, in Pmw (preferably
indicating the precise Pmw version).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 16:59

Message:
Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 03:57

Message:
Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 02:24

Message:
Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-12 19:12

Message:
Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

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

Comment By: John Speno (corvus)
Date: 2003-03-12 17:14

Message:
Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-11 23:39

Message:
Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 22:57

Message:
Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.


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

Comment By: John Speno (corvus)
Date: 2003-03-05 21:43

Message:
Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 20:40

Message:
Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 



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

Comment By: Jim Murff (jmurff)
Date: 2003-03-05 19:49

Message:
Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-05 03:18

Message:
Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

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

Comment By: John Speno (corvus)
Date: 2003-03-05 02:50

Message:
Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697591&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 07:51:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 23 Mar 2003 23:51:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT
Message-ID: 

Bugs item #663782, was opened at 2003-01-07 17:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_socket test_unicode_file fail on 2.3a1 on winNT

Initial Comment:
This happens after installing 2.3a1 on winNT 4 sp6.

D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_socket.py
testCrucialConstants (__main__.GeneralModuleTests) ... ok
testDefaultTimeout (__main__.GeneralModuleTests) ... ok
testGetServByName (__main__.GeneralModuleTests) ... ok
testGetSockOpt (__main__.GeneralModuleTests) ... ok
testHostnameRes (__main__.GeneralModuleTests) ... ok
testInterpreterCrash (__main__.GeneralModuleTests) ... ok
testNtoH (__main__.GeneralModuleTests) ... ok
testRefCountGetNameInfo (__main__.GeneralModuleTests)
... ok
testSendAfterClose (__main__.GeneralModuleTests) ... ok
testSetSockOpt (__main__.GeneralModuleTests) ... ok
testSockName (__main__.GeneralModuleTests) ... ok
testSocketError (__main__.GeneralModuleTests) ... ok
testFromFd (__main__.BasicTCPTest) ... ok
testOverFlowRecv (__main__.BasicTCPTest) ... ok
testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok
testRecv (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicTCPTest) ... ok
testSendAll (__main__.BasicTCPTest) ... ok
testShutdown (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicUDPTest) ... ok
testSendtoAndRecv (__main__.BasicUDPTest) ... ok
testAccept (__main__.NonBlockingTCPTests) ... FAIL
ERROR
testConnect (__main__.NonBlockingTCPTests) ... ok
testRecv (__main__.NonBlockingTCPTests) ... ok
testSetBlocking (__main__.NonBlockingTCPTests) ... ok
testFullRead (__main__.FileObjectClassTestCase) ... ok
testReadline (__main__.FileObjectClassTestCase) ... ok
testSmallRead (__main__.FileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.FileObjectClassTestCase)
... ok
testFullRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok

======================================================================
ERROR: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
117, in _tearDown
    self.fail(msg)
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: (10061, 'Connection refused')

======================================================================
FAIL: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
475, in testAccept
    self.fail("Error trying to do non-blocking accept.")
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: Error trying to do non-blocking accept.

----------------------------------------------------------------------
Ran 42 tests in 2.204s

FAILED (failures=1, errors=1)
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
632, in ?
    test_main()
  File "D:\apps\Python23\Lib\test\test_socket.py", line
629, in test_main
    test_support.run_suite(suite)
  File "D:\apps\Python23\lib\test\test_support.py",
line 217, in run_suite
    raise TestFailed(msg)
test.test_support.TestFailed: errors occurred; run in
verbose mode for details
D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_unicode_file.py
File doesn't exist (encoded string) after creating it
Traceback (most recent call last):
  File
"D:\apps\Python23\Lib\test\test_unicode_file.py", line
37, in ?
    if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE):
OSError: [Errno 2] No such file or directory: '@test-??'


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

>Comment By: Miki Tebeka (tebeka)
Date: 2003-03-24 09:51

Message:
Logged In: YES 
user_id=358087

Yes.
Version is:
2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)]

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 22:40

Message:
Logged In: YES 
user_id=33168

Is this problem still happening with 2.3a2+ ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 10:58:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 02:58:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 19:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-03-24 11:58

Message:
Logged In: YES 
user_id=45365

If this patch is accepted: may I request it be done soon? Changes like this often affect how things work on MacOS9 (IOW: break things on MacOS9:-), and in general changing the makefile() semantics on all non-windows platforms is something that may turn up hidden bugs, so I don't think we want this in as a last-second mod before 2.3b1 goes out.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 19:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 13:42:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 05:42:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-708806 ] memory leak in nested def()
Message-ID: 

Bugs item #708806, was opened at 2003-03-24 14:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708806&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Christian Tismer (tismer)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak in nested def()

Initial Comment:
I just tested generators and found a memory leak.
(Has nothing to do with generators).
The following code adds one to the overall refcount
and gc cannot reclaim it.

def conjoin(gs):
     def gen():
         gs      # unbreakable cycle
         gen     # unless one is commented out

The above holds for Python 2.2.2 upto the current CVS
version. I didn't try yet to investigate this further.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708806&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:09:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:09:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: 

Bugs item #708901, was opened at 2003-03-24 08:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:16:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:16:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: 

Bugs item #708901, was opened at 2003-03-24 17:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


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

>Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:21:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:21:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-24 04:58

Message:
Logged In: YES 
user_id=45365

If this patch is accepted: may I request it be done soon? Changes like this often affect how things work on MacOS9 (IOW: break things on MacOS9:-), and in general changing the makefile() semantics on all non-windows platforms is something that may turn up hidden bugs, so I don't think we want this in as a last-second mod before 2.3b1 goes out.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 12:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:23:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:23:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Neal Norwitz (nnorwitz)
Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-03-24 11:23

Message:
Logged In: YES 
user_id=44345

Jack, Any chance you can simply apply it to the source and see how it goes
on MacOS9? -Skip

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-24 04:58

Message:
Logged In: YES 
user_id=45365

If this patch is accepted: may I request it be done soon? Changes like this often affect how things work on MacOS9 (IOW: break things on MacOS9:-), and in general changing the makefile() semantics on all non-windows platforms is something that may turn up hidden bugs, so I don't think we want this in as a last-second mod before 2.3b1 goes out.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 12:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:36:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:36:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: 

Bugs item #708901, was opened at 2003-03-24 17:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


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

>Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:43:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:43:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: 

Bugs item #708901, was opened at 2003-03-24 17:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


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

>Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today , can you check
the attached patch?


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:48:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:48:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: 

Bugs item #708901, was opened at 2003-03-24 17:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Tim Peters (tim_one)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today , can you check
the attached patch?


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 17:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:58:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:58:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-708806 ] memory leak in nested def()
Message-ID: 

Bugs item #708806, was opened at 2003-03-24 08:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708806&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Christian Tismer (tismer)
>Assigned to: Tim Peters (tim_one)
Summary: memory leak in nested def()

Initial Comment:
I just tested generators and found a memory leak.
(Has nothing to do with generators).
The following code adds one to the overall refcount
and gc cannot reclaim it.

def conjoin(gs):
     def gen():
         gs      # unbreakable cycle
         gen     # unless one is commented out

The above holds for Python 2.2.2 upto the current CVS
version. I didn't try yet to investigate this further.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-24 12:58

Message:
Logged In: YES 
user_id=31435

Fixed.  The compiler was leaking a reference to the int 0, 
used to index an internal list.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708806&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 17:59:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 09:59:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-708927 ] socket timeouts produce wrong errors in win32
Message-ID: 

Bugs item #708927, was opened at 2003-03-24 08:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708927&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket timeouts produce wrong errors in win32

Initial Comment:
Here's a session:

Python 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import socket
>>> socket.setdefaulttimeout(0.01)
>>> import urllib
>>> urllib.urlopen('http://www.python.org')
Traceback (most recent call last):
  File "", line 1, in ?
  File "c:\Python23\lib\urllib.py", line 76, in urlopen
    return opener.open(url)
  File "c:\Python23\lib\urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "c:\Python23\lib\urllib.py", line 297, in open_http
    h.endheaders()
  File "c:\Python23\lib\httplib.py", line 705, in endheaders
    self._send_output()
  File "c:\Python23\lib\httplib.py", line 591, in 
_send_output
    self.send(msg)
  File "c:\Python23\lib\httplib.py", line 558, in send
    self.connect()
  File "c:\Python23\lib\httplib.py", line 798, in connect

IOError: [Errno socket error] (2, 'No such file or directory')
>>> urllib.urlopen('http://www.python.org')
< SNIP >

IOError: [Errno socket error] (0, 'Error')

Looking at socketmodule.c, it appears internal_connect 
must be taking the path which (under MS_WINDOWS) 
calls select to see if there was a timeout.  select must 
be returning 0 (to signal a timeout), but it apparently 
does not call WSASetLastError, so when set_error is 
called, WSAGetLastError returns 0, and the ultimate 
error generated comes from the call to 
PyErr_SetFromErrNo.  Perhaps in this case 
internal_connect should itself call WSASetLastError 
(with WSAETIMEDOUT rather than 
WSAEWOULDBLOCK?).

The reason I ran into this is I was planning to convert 
some code which used the timeoutsocket module under 
2.2.  That module raises a Timeout exception (which the 
code was catching) and I was trying to figure out what 
the equivalent exception would be from the normal 
socket module.  Perhaps the socket module should 
define some sort of timeout exception class so it would 
be easier to detect timeouts as opposed to other socket 
errors.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708927&group_id=5470


From noreply@sourceforge.net  Mon Mar 24 20:13:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 12:13:09 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase
Message-ID: 

Feature Requests item #708125, was opened at 2003-03-22 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Russell (mattruss)
>Assigned to: Steve Purcell (purcell)
Summary: Requesting Mock Object support for unittest.TestCase

Initial Comment:
I previously submitted a patch (sf id 706590),
since I was following www.python.com's notes on how 
to contribute - since using sf more i think i should of 
added it to this RFE. Since posting the orignal patch I 
have updated the code based upon sugestions from 
python-dev and others.

please view my origanal patch here:
https://sourceforge.net/tracker/index.php?
func=detail&aid=706590&group_id=5470&atid=305470

This patch adds one method - createMockInstance
(classDef, overrides, *initArgs, **initKwds)
to unittest.TestCase, and two classes MockFactory and 
MockMethod.

Since both these classes should never really be used 
outside the scope of a unittest, I thought it best to add 
them to the unittest module (allthough it is getting rather 
big - should be split into a package?)




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 04:03:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 24 Mar 2003 20:03:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT
Message-ID: 

Bugs item #663782, was opened at 2003-01-07 10:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_socket test_unicode_file fail on 2.3a1 on winNT

Initial Comment:
This happens after installing 2.3a1 on winNT 4 sp6.

D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_socket.py
testCrucialConstants (__main__.GeneralModuleTests) ... ok
testDefaultTimeout (__main__.GeneralModuleTests) ... ok
testGetServByName (__main__.GeneralModuleTests) ... ok
testGetSockOpt (__main__.GeneralModuleTests) ... ok
testHostnameRes (__main__.GeneralModuleTests) ... ok
testInterpreterCrash (__main__.GeneralModuleTests) ... ok
testNtoH (__main__.GeneralModuleTests) ... ok
testRefCountGetNameInfo (__main__.GeneralModuleTests)
... ok
testSendAfterClose (__main__.GeneralModuleTests) ... ok
testSetSockOpt (__main__.GeneralModuleTests) ... ok
testSockName (__main__.GeneralModuleTests) ... ok
testSocketError (__main__.GeneralModuleTests) ... ok
testFromFd (__main__.BasicTCPTest) ... ok
testOverFlowRecv (__main__.BasicTCPTest) ... ok
testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok
testRecv (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicTCPTest) ... ok
testSendAll (__main__.BasicTCPTest) ... ok
testShutdown (__main__.BasicTCPTest) ... ok
testRecvFrom (__main__.BasicUDPTest) ... ok
testSendtoAndRecv (__main__.BasicUDPTest) ... ok
testAccept (__main__.NonBlockingTCPTests) ... FAIL
ERROR
testConnect (__main__.NonBlockingTCPTests) ... ok
testRecv (__main__.NonBlockingTCPTests) ... ok
testSetBlocking (__main__.NonBlockingTCPTests) ... ok
testFullRead (__main__.FileObjectClassTestCase) ... ok
testReadline (__main__.FileObjectClassTestCase) ... ok
testSmallRead (__main__.FileObjectClassTestCase) ... ok
testUnbufferedRead (__main__.FileObjectClassTestCase)
... ok
testFullRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedReadline
(__main__.UnbufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.LineBufferedFileObjectClassTestCase) ... ok
testFullRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testReadline
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testSmallRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead
(__main__.SmallBufferedFileObjectClassTestCase) ... ok

======================================================================
ERROR: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
117, in _tearDown
    self.fail(msg)
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: (10061, 'Connection refused')

======================================================================
FAIL: testAccept (__main__.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
475, in testAccept
    self.fail("Error trying to do non-blocking accept.")
  File "D:\apps\Python23\lib\unittest.py", line 260, in
fail
    raise self.failureException, msg
AssertionError: Error trying to do non-blocking accept.

----------------------------------------------------------------------
Ran 42 tests in 2.204s

FAILED (failures=1, errors=1)
Traceback (most recent call last):
  File "D:\apps\Python23\Lib\test\test_socket.py", line
632, in ?
    test_main()
  File "D:\apps\Python23\Lib\test\test_socket.py", line
629, in test_main
    test_support.run_suite(suite)
  File "D:\apps\Python23\lib\test\test_support.py",
line 217, in run_suite
    raise TestFailed(msg)
test.test_support.TestFailed: errors occurred; run in
verbose mode for details
D:\apps\Python23>python
D:\apps\Python23\Lib\test\test_unicode_file.py
File doesn't exist (encoded string) after creating it
Traceback (most recent call last):
  File
"D:\apps\Python23\Lib\test\test_unicode_file.py", line
37, in ?
    if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE):
OSError: [Errno 2] No such file or directory: '@test-??'


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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-24 23:03

Message:
Logged In: YES 
user_id=31435

I personally tested these before the releases, on Win98SE 
and on Win2000 Pro.  No problems there, although 
test_unicode_file turns itself off on Win9x.  I don't have 
access to an NT box, and these won't get fixed until a 
Python developer who does have NT can dig into them 
there.

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

Comment By: Miki Tebeka (tebeka)
Date: 2003-03-24 02:51

Message:
Logged In: YES 
user_id=358087

Yes.
Version is:
2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)]

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:40

Message:
Logged In: YES 
user_id=33168

Is this problem still happening with 2.3a2+ ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 12:46:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 04:46:52 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase
Message-ID: 

Feature Requests item #708125, was opened at 2003-03-22 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Russell (mattruss)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Requesting Mock Object support for unittest.TestCase

Initial Comment:
I previously submitted a patch (sf id 706590),
since I was following www.python.com's notes on how 
to contribute - since using sf more i think i should of 
added it to this RFE. Since posting the orignal patch I 
have updated the code based upon sugestions from 
python-dev and others.

please view my origanal patch here:
https://sourceforge.net/tracker/index.php?
func=detail&aid=706590&group_id=5470&atid=305470

This patch adds one method - createMockInstance
(classDef, overrides, *initArgs, **initKwds)
to unittest.TestCase, and two classes MockFactory and 
MockMethod.

Since both these classes should never really be used 
outside the scope of a unittest, I thought it best to add 
them to the unittest module (allthough it is getting rather 
big - should be split into a package?)




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 13:48:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 05:48:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-709428 ] os.altsep is None under Windows
Message-ID: 

Bugs item #709428, was opened at 2003-03-25 04:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.altsep is None under Windows

Initial Comment:
With both 2.3a2 and 2.22, os.altsep is None under 
Windows.  This does not match the documentation, 
which states (in part): 'This is set to "/" on Windows 
systems where sep is a backslash.'  (Perhaps this is a 
documentation bug.)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 14:38:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 06:38:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-706592 ] Crbon.File.FSSpec should accept non-existing pathnames
Message-ID: 

Bugs item #706592, was opened at 2003-03-19 22:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Crbon.File.FSSpec should accept non-existing pathnames

Initial Comment:
Carbon.File.FSSpec currently doesn't accept non-existing pathnames.
This can be fixed in a way similar to what EasyDialogs.AskFileForSave uses, I think.

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

>Comment By: Michael Hudson (mwh)
Date: 2003-03-25 14:38

Message:
Logged In: YES 
user_id=6656

This would seem to be a dup of 585923 which is closed, fwiw.

I don't understand the comment about EasyDialogs.AskFileForSave.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 14:43:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 06:43:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-706592 ] Crbon.File.FSSpec should accept non-existing pathnames
Message-ID: 

Bugs item #706592, was opened at 2003-03-19 23:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Crbon.File.FSSpec should accept non-existing pathnames

Initial Comment:
Carbon.File.FSSpec currently doesn't accept non-existing pathnames.
This can be fixed in a way similar to what EasyDialogs.AskFileForSave uses, I think.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-03-25 15:43

Message:
Logged In: YES 
user_id=45365

I re-submitted this by popular demand. And, indeed, the logic could be similar to what AskFileForSave does (even though that is not 100% correct),
but this code has to be in C:-(

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-25 15:38

Message:
Logged In: YES 
user_id=6656

This would seem to be a dup of 585923 which is closed, fwiw.

I don't understand the comment about EasyDialogs.AskFileForSave.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 14:48:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 06:48:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-706592 ] Crbon.File.FSSpec should accept non-existing pathnames
Message-ID: 

Bugs item #706592, was opened at 2003-03-19 22:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Crbon.File.FSSpec should accept non-existing pathnames

Initial Comment:
Carbon.File.FSSpec currently doesn't accept non-existing pathnames.
This can be fixed in a way similar to what EasyDialogs.AskFileForSave uses, I think.

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

>Comment By: Michael Hudson (mwh)
Date: 2003-03-25 14:48

Message:
Logged In: YES 
user_id=6656

I know, you posted this after a complaint from me :-)

It seems to me that the hacks AskFileForSave perpetrates are
going the other way, from FSSpec of absent file to pathname.
 Can it be done backwards?  I guess pain comes from not
being able to call os.path.split in C...

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-25 14:43

Message:
Logged In: YES 
user_id=45365

I re-submitted this by popular demand. And, indeed, the logic could be similar to what AskFileForSave does (even though that is not 100% correct),
but this code has to be in C:-(

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-25 14:38

Message:
Logged In: YES 
user_id=6656

This would seem to be a dup of 585923 which is closed, fwiw.

I don't understand the comment about EasyDialogs.AskFileForSave.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 15:55:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 07:55:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-709491 ] sgmllib.SGMLParser.reset() problem
Message-ID: 

Bugs item #709491, was opened at 2003-03-25 10:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709491&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Gray (cpgray)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.SGMLParser.reset() problem

Initial Comment:
sgmllib.SGMLParser.reset() doesn't reset
__starttag_text to None

Here's an IDLE session illustrating the problem using
the subclass htmllib.HTMLParser:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more
information.
IDLE 0.8 -- press F1 for help
>>> import formatter
>>> import htmllib
>>> class HTMLP(htmllib.HTMLParser):
	def __init__(self):
		htmllib.HTMLParser.__init__(self,
formatter.NullFormatter())

>>> p = HTMLP()
>>> print p.get_starttag_text()
None
>>> p.feed('')
>>> print p.get_starttag_text()

>>> p.reset()
>>> print p.get_starttag_text()


The value for this last call to get_starttag_text()
should be None.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709491&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 16:11:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 08:11:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris
Message-ID: 

Bugs item #700780, was opened at 2003-03-10 11:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Iain Morrison (iainmorrison)
Assigned to: Nobody/Anonymous (nobody)
Summary: ncurses/curses on solaris

Initial Comment:
solaris 8 [sparc]
gcc 3.2.2
python 2.2.2

I am having trouble with curses support.  ncurses 5.3
is installed in the standard solaris manner

** Configuration summary for NCURSES 5.3 20021012:

      bin directory: /usr/local/bin
      lib directory: /usr/local/lib
  include directory: /usr/local/include/ncurses
      man directory: /usr/local/man
 terminfo directory: /usr/local/share/terminfo

** Include-directory is not in a standard location

is not picked up by ./configure.
 
checking for ncurses.h... no

Python builds fine but

./python ./Lib/test/test_curses.py -u curses
Traceback (most recent call last):
  File "./Lib/test/test_curses.py", line 11, in ?
    import curses, sys, tempfile
  File
"/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py",
line 15, in ?
    from _curses import *
ImportError: No module named _curses

I'm doing something wrong but I'm nor sure what.  Do I
need to have ncurses overwrite the default Solaris
curses? If so will anything break?


many thanks

iain morrison

iain.morrison@mrc-cbu.cam.ac.uk



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

>Comment By: Iain Morrison (iainmorrison)
Date: 2003-03-25 16:11

Message:
Logged In: YES 
user_id=720523

Using

setenv CPPFLAGS -I/usr/local/include/ncurses

and running

./configure


I get

checking for ncurses.h... yes


However the Makefile is identival to that produced without CPPFLAGS 
set. The curses test still fails

178 tests OK.
15 tests skipped:
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_email_codecs test_gdbm test_gl test_imgfile
    test_linuxaudiodev test_locale test_openpty test_winreg
    test_winsound

./python ./Lib/test/test_curses.py -u curses
Traceback (most recent call last):
  File "./Lib/test/test_curses.py", line 11, in ?
    import curses, sys, tempfile
  File "/usr/local/src/python/Python-2.2.2-test/Lib/curses/__init__.py", 
line 15, in ?
    from _curses import *
ImportError: No module named _curses



diff configure-output ../Python-2.2.2/configure-output
39c39
< checking for ncurses.h... yes
---
> checking for ncurses.h... no

diff Makefile ../Python-2.2.2/Makefile


Anything else I can try

iain

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 13:44

Message:
Logged In: YES 
user_id=21627

Did you expect to use ncurses, or did you mean to use curses?

What is the ncurses portion of running setup.py?

To eliminate setup.py problems, you can always edit
Modules/Setup.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-03-14 15:45

Message:
Logged In: YES 
user_id=11375

Your compiler may not be looking in /usr/local/ for headers and libraries.  You shouldn't install ncurses over Solaris curses; locally-installed software belongs in /usr/local/, period.

When you run the configure script, you can supply environment variables to add compiler flags; run configure --help to see a list.

I'd suggest something like 'CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure', and see if it picks up ncurses.h then.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 16:37:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 08:37:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-706592 ] Crbon.File.FSSpec should accept non-existing pathnames
Message-ID: 

Bugs item #706592, was opened at 2003-03-19 23:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Crbon.File.FSSpec should accept non-existing pathnames

Initial Comment:
Carbon.File.FSSpec currently doesn't accept non-existing pathnames.
This can be fixed in a way similar to what EasyDialogs.AskFileForSave uses, I think.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-03-25 17:37

Message:
Logged In: YES 
user_id=45365

Sort of. If the user wants an fsspec back you need to construct it. The difficult bit is getting the MacRoman (or whatever the local convention is)/utf-8 handling right. And then there's the 31-char limit for FSSpec filenames, which OSX handles with magic under the hood (but for non-existent files we don't have to worry about this).

But: if you're willing to do a 90% fix (say, by requiring ASCII in the last part of the filename): be my guest!

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-25 15:48

Message:
Logged In: YES 
user_id=6656

I know, you posted this after a complaint from me :-)

It seems to me that the hacks AskFileForSave perpetrates are
going the other way, from FSSpec of absent file to pathname.
 Can it be done backwards?  I guess pain comes from not
being able to call os.path.split in C...

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-25 15:43

Message:
Logged In: YES 
user_id=45365

I re-submitted this by popular demand. And, indeed, the logic could be similar to what AskFileForSave does (even though that is not 100% correct),
but this code has to be in C:-(

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-25 15:38

Message:
Logged In: YES 
user_id=6656

This would seem to be a dup of 585923 which is closed, fwiw.

I don't understand the comment about EasyDialogs.AskFileForSave.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706592&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 17:51:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 09:51:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 15:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Richard Townsend (rptownsend)
Date: 2003-03-25 17:51

Message:
Logged In: YES 
user_id=200117

Neal,

The original error referred to unresolved 
symbol 'libiconv_open'.

The source module _iconv_codec.c contains calls to 
iconv_open(), not libiconv_open().

However, if I recompile it with the -E flag there is a pre-
processor substitution happening which is converting 
all instances of 'iconv' to 'libiconv'

Here I grepped the pre-processor output for 'iconv'...

extern int _libiconv_version;
typedef void* libiconv_t ;
extern libiconv_t  libiconv_open  (const char* tocode, 
const char* fromcode);
extern size_t libiconv  (libiconv_t  cd,  char* * inbuf, 
size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
extern int libiconv_close  (libiconv_t  cd);
extern int libiconvctl  (libiconv_t  cd, int request, void* 
argument);
    libiconv_t   enchdl, dechdl;
        if (libiconv (self->enchdl, (char**)&inp, &inplen, 
&out, &outlen)
        size_t res = libiconv (self->dechdl, (char**)&inp, 
&inplen, &out, &outlen);
    new->enchdl = new->dechdl = (libiconv_t )(-1);
    new->dechdl = libiconv_open ("ucs-2-internal" , 
new->encoding);
    if (new->dechdl == (libiconv_t )(-1)) {
    new->enchdl = libiconv_open (new->encoding, "ucs-
2-internal" );
    if (new->enchdl == (libiconv_t )(-1)) {
        libiconv_close (new->dechdl);
        new->dechdl = (libiconv_t )(-1);
    if (self->enchdl != (libiconv_t )-1)
        libiconv_close (self->enchdl);
    if (self->dechdl != (libiconv_t )-1)
        libiconv_close (self->dechdl);
    libiconv_t  hdl = libiconv_open ("ucs-2-
internal" , "ISO-8859-1");
    if (hdl == (libiconv_t )-1) {
    res = libiconv (hdl, &inptr, &insize, &outptr, &outsize);
        libiconv_close (hdl);
    libiconv_close (hdl);

Is this supposed to be happening??

If not, what could be causing it??



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:52

Message:
Logged In: YES 
user_id=33168

Looking further into the python configure, I see that the
option is --with-dl-dld, however, this option is not
supported.  Can try to play with the build options to find
the magic that works on your version of HPUX?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 17:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 22:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 09:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 17:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 03:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 22:21:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 14:21:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-706253 ] python accepts illegal "import mod.sub as name" syntax
Message-ID: 

Bugs item #706253, was opened at 2003-03-19 06:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: python accepts illegal "import mod.sub as name" syntax

Initial Comment:
http://python.org/doc/current/ref/import.html
"To avoid confusion, you cannot import modules with
dotted names as a different local name. So import
module as m is legal, but import module.submod as s is
not."

sadly the interpreter accepts the illegal form without
comment which makes it "semi-legal".
packages that rely on this illegal form may cause
trouble with costum import implementations (i.e.
importing from zip file or similar)

tested with 2.2.2 and 2.3a2

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

Comment By: logistix (logistix)
Date: 2003-03-25 16:21

Message:
Logged In: YES 
user_id=699438

Here's a case where I think the documentation should be 
fixed instead of the bug.  Every COM project I do starts 
with 'import win32com.client as client'.  I also don't see how 
one syntax is any more confusing than the other.  And even if 
the above syntax was illegal, you could still do something like:

>>> import win32com.client
>>> server = win32com.client

If you really wanted to be confusing.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470


From noreply@sourceforge.net  Tue Mar 25 22:58:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 14:58:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-709733 ] PyWeakref_GetObject incorrectly documented
Message-ID: 

Bugs item #709733, was opened at 2003-03-25 22:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709733&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Stone (mbrierst)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyWeakref_GetObject incorrectly documented

Initial Comment:

It returns None, not NULL when the object has gone away.
I got burned by this.
A quick perusal of the code shows it to be true.
Doc patch attached.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709733&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 03:55:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 19:55:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug
Message-ID: 

Bugs item #702775, was opened at 2003-03-13 15:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jane Austine (janeaustine50)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm __del__ bug

Initial Comment:
I used shelve.py and it falls back on dumbdbm when no
possible alternatives are found on the system.

I found this error, which is recurrent and deterministic:

Exception exceptions.AttributeError: "'NoneType' object 
has no
attribute 'error'" in > ignored

The problem seems to reside in the __del__ of 
dumbdbm._Database:

class _Database:
...
    def __del__(self):
        if self._index is not None:
            self._commit()
...
    def _commit(self):
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        f = _open(self._dirfile, 'w', self._mode)
        for key, (pos, siz) in self._index.items():
            f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`))
        f.close()

My investigation showed that the error was from 
_commit. When
it was called, _os or _open was both None. And the 
exception
catch didn't work quite safely cause its in the "except" 
clause.

The reason I suspect is when the time that 
_Database.__del__ was
called the os module(which is imported as _os) is 
already removed out.

I changed the code as:

    def _commit(self):
        global _os
        if _os is None:
            import os as _os
            import __builtin__
            _open = __builtin__.open
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        ......

Now it works without any problems, AFAIK.



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

>Comment By: Jane Austine (janeaustine50)
Date: 2003-03-26 12:55

Message:
Logged In: YES 
user_id=732903

A test case that triggers this problem:

#foobar.py
def open(filename, flag='c'):
    import dumbdbm
    return dumbdbm.open(filename,flag)

c=open('test.dbm')

#main.py
import foobar

$ python main.py
>>> 
Exception exceptions.TypeError: "'NoneType' object is not 
callable" in > ignored

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 10:06

Message:
Logged In: YES 
user_id=33168

Can you provide a test case which triggers this problem?  I
can't see how _os becomes None.  Also I would like to add a
test.  Thanks.

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

Comment By: June Kim (juneaftn)
Date: 2003-03-14 02:02

Message:
Logged In: YES 
user_id=116941

see the thread at http://groups.google.com/groups?
selm=ba1e306f.0303111337.72a696c7%
40posting.google.com , esp. by my name.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 04:04:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 20:04:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug
Message-ID: 

Bugs item #702775, was opened at 2003-03-13 15:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jane Austine (janeaustine50)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm __del__ bug

Initial Comment:
I used shelve.py and it falls back on dumbdbm when no
possible alternatives are found on the system.

I found this error, which is recurrent and deterministic:

Exception exceptions.AttributeError: "'NoneType' object 
has no
attribute 'error'" in > ignored

The problem seems to reside in the __del__ of 
dumbdbm._Database:

class _Database:
...
    def __del__(self):
        if self._index is not None:
            self._commit()
...
    def _commit(self):
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        f = _open(self._dirfile, 'w', self._mode)
        for key, (pos, siz) in self._index.items():
            f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`))
        f.close()

My investigation showed that the error was from 
_commit. When
it was called, _os or _open was both None. And the 
exception
catch didn't work quite safely cause its in the "except" 
clause.

The reason I suspect is when the time that 
_Database.__del__ was
called the os module(which is imported as _os) is 
already removed out.

I changed the code as:

    def _commit(self):
        global _os
        if _os is None:
            import os as _os
            import __builtin__
            _open = __builtin__.open
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        ......

Now it works without any problems, AFAIK.



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

>Comment By: Jane Austine (janeaustine50)
Date: 2003-03-26 13:04

Message:
Logged In: YES 
user_id=732903

Run the main.py in Python 2.3+ putting the two files in the 
same place.

For Python 2.2+, put the two files in the same package and 
make a new file that imports main.py and run it as follows:

=======
from  import main
=======

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-26 12:55

Message:
Logged In: YES 
user_id=732903

A test case that triggers this problem:

#foobar.py
def open(filename, flag='c'):
    import dumbdbm
    return dumbdbm.open(filename,flag)

c=open('test.dbm')

#main.py
import foobar

$ python main.py
>>> 
Exception exceptions.TypeError: "'NoneType' object is not 
callable" in > ignored

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 10:06

Message:
Logged In: YES 
user_id=33168

Can you provide a test case which triggers this problem?  I
can't see how _os becomes None.  Also I would like to add a
test.  Thanks.

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

Comment By: June Kim (juneaftn)
Date: 2003-03-14 02:02

Message:
Logged In: YES 
user_id=116941

see the thread at http://groups.google.com/groups?
selm=ba1e306f.0303111337.72a696c7%
40posting.google.com , esp. by my name.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 04:08:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 20:08:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug
Message-ID: 

Bugs item #702775, was opened at 2003-03-13 15:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jane Austine (janeaustine50)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm __del__ bug

Initial Comment:
I used shelve.py and it falls back on dumbdbm when no
possible alternatives are found on the system.

I found this error, which is recurrent and deterministic:

Exception exceptions.AttributeError: "'NoneType' object 
has no
attribute 'error'" in > ignored

The problem seems to reside in the __del__ of 
dumbdbm._Database:

class _Database:
...
    def __del__(self):
        if self._index is not None:
            self._commit()
...
    def _commit(self):
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        f = _open(self._dirfile, 'w', self._mode)
        for key, (pos, siz) in self._index.items():
            f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`))
        f.close()

My investigation showed that the error was from 
_commit. When
it was called, _os or _open was both None. And the 
exception
catch didn't work quite safely cause its in the "except" 
clause.

The reason I suspect is when the time that 
_Database.__del__ was
called the os module(which is imported as _os) is 
already removed out.

I changed the code as:

    def _commit(self):
        global _os
        if _os is None:
            import os as _os
            import __builtin__
            _open = __builtin__.open
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        ......

Now it works without any problems, AFAIK.



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

>Comment By: Jane Austine (janeaustine50)
Date: 2003-03-26 13:08

Message:
Logged In: YES 
user_id=732903

Tested on linux and windows xp with Python2.2.2 and 
Python2.3a2. 

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-26 13:04

Message:
Logged In: YES 
user_id=732903

Run the main.py in Python 2.3+ putting the two files in the 
same place.

For Python 2.2+, put the two files in the same package and 
make a new file that imports main.py and run it as follows:

=======
from  import main
=======

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-26 12:55

Message:
Logged In: YES 
user_id=732903

A test case that triggers this problem:

#foobar.py
def open(filename, flag='c'):
    import dumbdbm
    return dumbdbm.open(filename,flag)

c=open('test.dbm')

#main.py
import foobar

$ python main.py
>>> 
Exception exceptions.TypeError: "'NoneType' object is not 
callable" in > ignored

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 10:06

Message:
Logged In: YES 
user_id=33168

Can you provide a test case which triggers this problem?  I
can't see how _os becomes None.  Also I would like to add a
test.  Thanks.

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

Comment By: June Kim (juneaftn)
Date: 2003-03-14 02:02

Message:
Logged In: YES 
user_id=116941

see the thread at http://groups.google.com/groups?
selm=ba1e306f.0303111337.72a696c7%
40posting.google.com , esp. by my name.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 04:09:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 25 Mar 2003 20:09:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug
Message-ID: 

Bugs item #702775, was opened at 2003-03-13 01:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jane Austine (janeaustine50)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm __del__ bug

Initial Comment:
I used shelve.py and it falls back on dumbdbm when no
possible alternatives are found on the system.

I found this error, which is recurrent and deterministic:

Exception exceptions.AttributeError: "'NoneType' object 
has no
attribute 'error'" in > ignored

The problem seems to reside in the __del__ of 
dumbdbm._Database:

class _Database:
...
    def __del__(self):
        if self._index is not None:
            self._commit()
...
    def _commit(self):
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        f = _open(self._dirfile, 'w', self._mode)
        for key, (pos, siz) in self._index.items():
            f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`))
        f.close()

My investigation showed that the error was from 
_commit. When
it was called, _os or _open was both None. And the 
exception
catch didn't work quite safely cause its in the "except" 
clause.

The reason I suspect is when the time that 
_Database.__del__ was
called the os module(which is imported as _os) is 
already removed out.

I changed the code as:

    def _commit(self):
        global _os
        if _os is None:
            import os as _os
            import __builtin__
            _open = __builtin__.open
        try: _os.unlink(self._bakfile)
        except _os.error: pass
        try: _os.rename(self._dirfile, self._bakfile)
        except _os.error: pass
        ......

Now it works without any problems, AFAIK.



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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-25 23:09

Message:
Logged In: YES 
user_id=31435

Neal, this is actually a common problem in __del__ 
methods, and the OP's analysis is on target.  When Python 
is shutting down, it tries to tear down module dicts in a 
safe-as-possible order, but modules are full of reference 
cycles and there is no *wholly* safe order.

In general, a __del__ method should never reference 
globals because of this.  The usual solution can be seen in 
tempfile.py:  store the global objects __del__ will need as 
class attributes when the class is created, and refer to 
these bindings in __del__ via self.attrname 
(ClassName.attrname is also no good, because it refers to 
the global ClassName!  that may also become None).

Reimporting a module instead may not be effective (if it's in 
a partially torn-doiwn state but its name is still a key in 
sys.modules, importing again will just retrieve the partially 
torn-down module object).  The class-attr trick is robust.

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-25 23:08

Message:
Logged In: YES 
user_id=732903

Tested on linux and windows xp with Python2.2.2 and 
Python2.3a2. 

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-25 23:04

Message:
Logged In: YES 
user_id=732903

Run the main.py in Python 2.3+ putting the two files in the 
same place.

For Python 2.2+, put the two files in the same package and 
make a new file that imports main.py and run it as follows:

=======
from  import main
=======

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

Comment By: Jane Austine (janeaustine50)
Date: 2003-03-25 22:55

Message:
Logged In: YES 
user_id=732903

A test case that triggers this problem:

#foobar.py
def open(filename, flag='c'):
    import dumbdbm
    return dumbdbm.open(filename,flag)

c=open('test.dbm')

#main.py
import foobar

$ python main.py
>>> 
Exception exceptions.TypeError: "'NoneType' object is not 
callable" in > ignored

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 20:06

Message:
Logged In: YES 
user_id=33168

Can you provide a test case which triggers this problem?  I
can't see how _os becomes None.  Also I would like to add a
test.  Thanks.

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

Comment By: June Kim (juneaftn)
Date: 2003-03-13 12:02

Message:
Logged In: YES 
user_id=116941

see the thread at http://groups.google.com/groups?
selm=ba1e306f.0303111337.72a696c7%
40posting.google.com , esp. by my name.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 13:43:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 05:43:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-710041 ] sys.stdout IOError under Windows
Message-ID: 

Bugs item #710041, was opened at 2003-03-26 13:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.stdout IOError under Windows

Initial Comment:
Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32.

Under Windoze 98, in a non-console application 
(pythonw.exe) the sys.std[in|out|err] file objects' fileno() 
returns -1.

Which is fine.  Calls to the write() methods seem to discard 
the data, which is what I want (when running a 
cross-platform GUI program with debug print statements).

BUT, when the write() method is called with more than 
about 4KB, it raises "IOError: [Errno 9] Bad file descriptor", 
the same as if you had manually called the flush() method.

This IOError happens when write()ing even one character 
if "pythonw.exe -u" was used to start the GUI.

I work around it by defining my own bit-bucket for 
sys.std[out|err].

(NOTE: This bug was hard to track down!)

Thanks guys|gals.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 13:56:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 05:56:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-710041 ] sys.stdout IOError under Windows
Message-ID: 

Bugs item #710041, was opened at 2003-03-26 13:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.stdout IOError under Windows

Initial Comment:
Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32.

Under Windoze 98, in a non-console application 
(pythonw.exe) the sys.std[in|out|err] file objects' fileno() 
returns -1.

Which is fine.  Calls to the write() methods seem to discard 
the data, which is what I want (when running a 
cross-platform GUI program with debug print statements).

BUT, when the write() method is called with more than 
about 4KB, it raises "IOError: [Errno 9] Bad file descriptor", 
the same as if you had manually called the flush() method.

This IOError happens when write()ing even one character 
if "pythonw.exe -u" was used to start the GUI.

I work around it by defining my own bit-bucket for 
sys.std[out|err].

(NOTE: This bug was hard to track down!)

Thanks guys|gals.

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

>Comment By: Graham Horler (grahamh)
Date: 2003-03-26 13:56

Message:
Logged In: YES 
user_id=543663

Hey, I just noticed another bug report has this same problem:
[ 706263 ] print raises exception when no console available


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 13:56:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 05:56:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-710041 ] sys.stdout IOError under Windows
Message-ID: 

Bugs item #710041, was opened at 2003-03-26 13:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.stdout IOError under Windows

Initial Comment:
Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32.

Under Windoze 98, in a non-console application 
(pythonw.exe) the sys.std[in|out|err] file objects' fileno() 
returns -1.

Which is fine.  Calls to the write() methods seem to discard 
the data, which is what I want (when running a 
cross-platform GUI program with debug print statements).

BUT, when the write() method is called with more than 
about 4KB, it raises "IOError: [Errno 9] Bad file descriptor", 
the same as if you had manually called the flush() method.

This IOError happens when write()ing even one character 
if "pythonw.exe -u" was used to start the GUI.

I work around it by defining my own bit-bucket for 
sys.std[out|err].

(NOTE: This bug was hard to track down!)

Thanks guys|gals.

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

Comment By: Graham Horler (grahamh)
Date: 2003-03-26 13:56

Message:
Logged In: YES 
user_id=543663

Hey, I just noticed another bug report has this same problem:
[ 706263 ] print raises exception when no console available


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 14:00:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 06:00:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-706263 ] print raises exception when no console available
Message-ID: 

Bugs item #706263, was opened at 2003-03-19 13:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Mark Hammond (mhammond)
Summary: print raises exception when no console available

Initial Comment:
platform: win2k
testet with: 2.2.2   2.3a1   2.3a2

the test case works fine when the script is run with
python.exe. with pythonw.exe an exception is raised
after printing 4096 bytes. the exception is rather
obscure but the bytecount suggests a buffer overflow.

print (or to be more exact sys.stdout.write) should be
a noop when there is no console.


test case:
import traceback
counter = 0
try:
	for counter in range(100000):
		print 'a',
	success_file = open('success.txt', 'w')
	success_file.write('Bytes printed: %d\n' % (counter*2))
	success_file.close()
except:
	error_file = open('error.txt', 'w')
	error_file.write('Bytes printed before exception was
raised: %d\n' % (counter*2))
	traceback.print_exc(100, error_file)
	error_file.close()


output:
Bytes printed before exception was raised: 4096
Traceback (most recent call last):
  File "test_case.py", line 5, in ?
    print 'a',
IOError: [Errno 9] Bad file descriptor


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

Comment By: Graham Horler (grahamh)
Date: 2003-03-26 13:59

Message:
Logged In: YES 
user_id=543663

I just submitted a bug report ([ 710041 ] sys.stdout IOError 
under Windows) with this same problem, so I closed it and will 
add some of my comments here, in the hopes they will be 
useful:

Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32.
Under Windoze 98, in a non-console application.

Calls to the write() methods seem to discard  the data, which 
is what I want (when running a cross-platform GUI program 
with debug print statements).

BUT, when the write() method is called with more than 
about 4KB, it raises "IOError: [Errno 9] Bad file descriptor", 
the same as if you had manually called the flush() method.

This IOError happens when write()ing even one character 
if "pythonw.exe -u" was used to start the GUI.

I work around it by defining my own bit-bucket for 
sys.std[out|err].
(NOTE: This bug was hard to track down!)


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

Comment By: Alexander Miseler (amiseler)
Date: 2003-03-20 13:40

Message:
Logged In: YES 
user_id=693638

and to say something FOR noop:
tim_one: "(nobody would write to stdout or stderr
*intending* the output be lost)"

yes, but someone would use print in an application and still
intend this application to run on any platform supported by
python.
its not really intuitive for someone programming under linux
that the print statement may limit the portability.

btw: the microsoft implementations (visual studio) of printf
and cout seem to be noops for non-console applications.
no idea how other windows compilers (mingw?) handle this.

i would consider it best, to make sys.stdout.write a noop
but to provide some other means to inquire the availability
of text output.

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

Comment By: Alexander Miseler (amiseler)
Date: 2003-03-20 09:19

Message:
Logged In: YES 
user_id=693638

then please throw a meaningful exception at first byte
written, not an obscure exception after 4096 bytes written.


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

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 04:17

Message:
Logged In: YES 
user_id=31435

I can swing either way on this, or even a third:  open text 
files stdout.txt and stderr.txt in the current directory then.  
That's really aiming at a different irritation, though, that 
tracebacks end up in the bit bucket by default under 
pythonw.

BTW, making stdout and stderr /dev/null workalikes is 
least attractive to me (nobody would write to stdout or 
stderr *intending* the output be lost).  I'm (barely) OK with 
letting it stay as it is, because that just reflects Windows 
reality.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-03-19 23:51

Message:
Logged In: YES 
user_id=14198

I struck this years ago, but was in a quandry.  On one hand,
sys.stdout *is* invalid, and I see no reason why Python
should mask these errors.  There may be real applications
where this failure *must* be reported to the program rather
than simply consumed.

However, I see the point that print is so basic that is
should never fail.  To my mind, the first point outweighs
the first, and the problem is fairly simply solved (see if
sys.stdout is invalid, and if so, open a file and set it to
that).

So I am afraid that, no, I don't give a rats .  Unless
conivenced otherwise (ie, by Tim or Guido) I will close this
as "not a bug" in a week or so.

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 17:18

Message:
Logged In: YES 
user_id=31435

Mark, give a rip ?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706263&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 14:02:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 06:02:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-710041 ] sys.stdout IOError under Windows
Message-ID: 

Bugs item #710041, was opened at 2003-03-26 13:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
>Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.stdout IOError under Windows

Initial Comment:
Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32.

Under Windoze 98, in a non-console application 
(pythonw.exe) the sys.std[in|out|err] file objects' fileno() 
returns -1.

Which is fine.  Calls to the write() methods seem to discard 
the data, which is what I want (when running a 
cross-platform GUI program with debug print statements).

BUT, when the write() method is called with more than 
about 4KB, it raises "IOError: [Errno 9] Bad file descriptor", 
the same as if you had manually called the flush() method.

This IOError happens when write()ing even one character 
if "pythonw.exe -u" was used to start the GUI.

I work around it by defining my own bit-bucket for 
sys.std[out|err].

(NOTE: This bug was hard to track down!)

Thanks guys|gals.

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

Comment By: Graham Horler (grahamh)
Date: 2003-03-26 13:56

Message:
Logged In: YES 
user_id=543663

Hey, I just noticed another bug report has this same problem:
[ 706263 ] print raises exception when no console available


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710041&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 14:43:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 06:43:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 15:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 14:43

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I have now discovered that there is a different version of 
iconv.h on my workstation in /usr/local/include.

It appears to be part of the zlib package and it contains 
the pre-processor macros which are converting the 
iconv statements to libiconv.

It is being used instead of the one in /usr/include, 
because the compile command contains 
-I/usr/local/include 

Is there any easy to prevent this path from being added 
to the compile commands? 



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-25 17:51

Message:
Logged In: YES 
user_id=200117

Neal,

The original error referred to unresolved 
symbol 'libiconv_open'.

The source module _iconv_codec.c contains calls to 
iconv_open(), not libiconv_open().

However, if I recompile it with the -E flag there is a pre-
processor substitution happening which is converting 
all instances of 'iconv' to 'libiconv'

Here I grepped the pre-processor output for 'iconv'...

extern int _libiconv_version;
typedef void* libiconv_t ;
extern libiconv_t  libiconv_open  (const char* tocode, 
const char* fromcode);
extern size_t libiconv  (libiconv_t  cd,  char* * inbuf, 
size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
extern int libiconv_close  (libiconv_t  cd);
extern int libiconvctl  (libiconv_t  cd, int request, void* 
argument);
    libiconv_t   enchdl, dechdl;
        if (libiconv (self->enchdl, (char**)&inp, &inplen, 
&out, &outlen)
        size_t res = libiconv (self->dechdl, (char**)&inp, 
&inplen, &out, &outlen);
    new->enchdl = new->dechdl = (libiconv_t )(-1);
    new->dechdl = libiconv_open ("ucs-2-internal" , 
new->encoding);
    if (new->dechdl == (libiconv_t )(-1)) {
    new->enchdl = libiconv_open (new->encoding, "ucs-
2-internal" );
    if (new->enchdl == (libiconv_t )(-1)) {
        libiconv_close (new->dechdl);
        new->dechdl = (libiconv_t )(-1);
    if (self->enchdl != (libiconv_t )-1)
        libiconv_close (self->enchdl);
    if (self->dechdl != (libiconv_t )-1)
        libiconv_close (self->dechdl);
    libiconv_t  hdl = libiconv_open ("ucs-2-
internal" , "ISO-8859-1");
    if (hdl == (libiconv_t )-1) {
    res = libiconv (hdl, &inptr, &insize, &outptr, &outsize);
        libiconv_close (hdl);
    libiconv_close (hdl);

Is this supposed to be happening??

If not, what could be causing it??



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:52

Message:
Logged In: YES 
user_id=33168

Looking further into the python configure, I see that the
option is --with-dl-dld, however, this option is not
supported.  Can try to play with the build options to find
the magic that works on your version of HPUX?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 17:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 22:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 09:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 17:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 03:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 16:26:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 08:26:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 15:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 16:26

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I edited Modules/Setup line 483 like this:

_iconv_codec _iconv_codec.c -I/usr/include

I can now build Python! 

However test_iconv_codecs fails:

capulet:dist/src 
> ./python ./Lib/test/test_iconv_codecs.py
Traceback (most recent call last):
  File "./Lib/test/test_iconv_codecs.py", line 3, in ?
    import codecs, _iconv_codec
RuntimeError: can't initialize the _iconv_codec module: 
iconv_open() failed


I tried adding '-l:libdld.sl' to line 483 (as suggested by 
the man page) but
the test still fails.



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 14:43

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I have now discovered that there is a different version of 
iconv.h on my workstation in /usr/local/include.

It appears to be part of the zlib package and it contains 
the pre-processor macros which are converting the 
iconv statements to libiconv.

It is being used instead of the one in /usr/include, 
because the compile command contains 
-I/usr/local/include 

Is there any easy to prevent this path from being added 
to the compile commands? 



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-25 17:51

Message:
Logged In: YES 
user_id=200117

Neal,

The original error referred to unresolved 
symbol 'libiconv_open'.

The source module _iconv_codec.c contains calls to 
iconv_open(), not libiconv_open().

However, if I recompile it with the -E flag there is a pre-
processor substitution happening which is converting 
all instances of 'iconv' to 'libiconv'

Here I grepped the pre-processor output for 'iconv'...

extern int _libiconv_version;
typedef void* libiconv_t ;
extern libiconv_t  libiconv_open  (const char* tocode, 
const char* fromcode);
extern size_t libiconv  (libiconv_t  cd,  char* * inbuf, 
size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
extern int libiconv_close  (libiconv_t  cd);
extern int libiconvctl  (libiconv_t  cd, int request, void* 
argument);
    libiconv_t   enchdl, dechdl;
        if (libiconv (self->enchdl, (char**)&inp, &inplen, 
&out, &outlen)
        size_t res = libiconv (self->dechdl, (char**)&inp, 
&inplen, &out, &outlen);
    new->enchdl = new->dechdl = (libiconv_t )(-1);
    new->dechdl = libiconv_open ("ucs-2-internal" , 
new->encoding);
    if (new->dechdl == (libiconv_t )(-1)) {
    new->enchdl = libiconv_open (new->encoding, "ucs-
2-internal" );
    if (new->enchdl == (libiconv_t )(-1)) {
        libiconv_close (new->dechdl);
        new->dechdl = (libiconv_t )(-1);
    if (self->enchdl != (libiconv_t )-1)
        libiconv_close (self->enchdl);
    if (self->dechdl != (libiconv_t )-1)
        libiconv_close (self->dechdl);
    libiconv_t  hdl = libiconv_open ("ucs-2-
internal" , "ISO-8859-1");
    if (hdl == (libiconv_t )-1) {
    res = libiconv (hdl, &inptr, &insize, &outptr, &outsize);
        libiconv_close (hdl);
    libiconv_close (hdl);

Is this supposed to be happening??

If not, what could be causing it??



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:52

Message:
Logged In: YES 
user_id=33168

Looking further into the python configure, I see that the
option is --with-dl-dld, however, this option is not
supported.  Can try to play with the build options to find
the magic that works on your version of HPUX?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 17:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 22:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 09:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 17:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 03:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 17:05:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 09:05:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-707576 ] -i -u options give SyntaxError on Windows
Message-ID: 

Bugs item #707576, was opened at 2003-03-21 15:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 3
Submitted By: Chris Withers (fresh)
Assigned to: Tim Peters (tim_one)
Summary: -i -u options give SyntaxError on Windows

Initial Comment:
C:\>python -i -u
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.
>>> print 1
  File "", line 1
    print 1
           ^
SyntaxError: invalid syntax
>>>

...and this behaviour continues, no mater what
statement you enter.

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

>Comment By: Chris Withers (fresh)
Date: 2003-03-26 17:05

Message:
Logged In: YES 
user_id=24723

-u     : unbuffered binary stdout and stderr (also
PYTHONUNBUFFERED=x)

Hmmm... never noticed the binary bit before. 
Is there any way to get unbuffered output without it being
binary?

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-21 16:30

Message:
Logged In: YES 
user_id=31435

Why do you call this a bug?  -u forces stdin into binary mode, 
and the Python grammar does not allow \r\n line endings in 
program text (it never has, BTW).  Program text has to come 
from a file opened in text mode on Windows, and what you're 
seeing here is the same as what you'd see if you did

f = open('some_python_program.py', 'rb')
exec f.read()

on Windows.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 17:59:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 09:59:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-710197 ] initialisation problem with dict.fromkeys()
Message-ID: 

Bugs item #710197, was opened at 2003-03-26 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Sohm (fsms)
Assigned to: Nobody/Anonymous (nobody)
Summary: initialisation problem with dict.fromkeys()

Initial Comment:
I have a problem of initialization of dictionary with the new method  
dict.fromkeys(sequence [, defaults]) when defaults is a list.  
  
here an example :  
  
Python 2.3a2 (#1, Feb 21 2003, 14:28:59)   
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2  
Type "copyright", "credits" or "license" for more information.  
IDLEfork 0.9a2  
>>> a = {}.fromkeys([0, 1], [ ])  
>>> a[0]  
[ ]  
>>> a[1]  
[ ]  
>>> a[0] += [2]  
>>> a[0]  
[2]  
>>> a[1]  
[2]  
>>> a[1] is a[0]  
True  
>>> a[0].append(3)  
>>> a[0]  
[2, 3]  
>>> a[1]  
[2, 3]  
etc... same thing if I use list() instead of [ ] 
  
the same list seems to be assigned to all the keys.  
when using string, tuple... it is normal (or what I would expect at 
least) : 
>>> b = {}.fromkeys([0,1], '') 
>>> b[0] 
'' 
>>> b[1] 
'' 
>>> b[0] += '2' 
>>> b[0] 
'2' 
>>> b[1] 
'' 
>>>b[0] is b[1] 
False 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 19:48:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 11:48:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 10:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 21:30:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 13:30:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 11:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Jason Tishler (jlt63)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

>Comment By: Jason Tishler (jlt63)
Date: 2003-03-26 12:30

Message:
Logged In: YES 
user_id=86216

loewis> Building _tkinter without threads should be supported.

Does the above imply that this is a generic Unix as oppose to
Cygwin specific problem?


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 09:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-18 18:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-18 18:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 15:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 22:30:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 14:30:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-710373 ] IDE stdin doesn't have readlines
Message-ID: 

Bugs item #710373, was opened at 2003-03-26 23:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710373&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE stdin doesn't have readlines

Initial Comment:
This was submitted by email by macrulezatsofthomedotnet. It looks reasonable, but please have a look too.

SimpleStdin doesn't provide a readlines method
	some scripts call sys.stdin.readlines(). the default stdin does not support this behaviour. I added it by copying and pasting the readlines method from StringIO, and adapting the indentation to fit. works beautifully: it asks the user for a line of input repeatedly until the user clicks 'Cancel'. not perfect UI, but it's something.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710373&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 22:33:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 14:33:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-710374 ] Raise IDE output window over splash screen on early crash
Message-ID: 

Bugs item #710374, was opened at 2003-03-26 23:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: Raise IDE output window over splash screen on early crash

Initial Comment:
This one was also submitted by macrulezatsofthomedotnet, but I'm not so sure about it. What do you think, would changing the DLOG resource for the splash screen have other, unforeseen side effects?
The effect of the change I would dearly like: how often have I cursed the %#$ spalsh screen being in front of the error message I would really love to see...

Sometimes the script short-circuits while Python IDE is starting
	actually, I haven't fixed that yet, but I did get around the problem of it preventing Python from starting (which is a problem because the user then cannot quit). I ResEdited the Python IDE and changed the 'DLOG' resource, such that the 'About' dialogue (the splash screen) is a window, rather than an actual dialogue. thus, when the  window appears (showing a traceback), it moves to the frontmost instead of remaining behind the splash where it can't be read.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470


From noreply@sourceforge.net  Wed Mar 26 22:59:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 14:59:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 21:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Jason Tishler (jlt63)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-26 23:59

Message:
Logged In: YES 
user_id=21627

This is my suspicion. I haven't tried building Python on a
Unix system without threads, but I suspect it fails as well.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-26 22:30

Message:
Logged In: YES 
user_id=86216

loewis> Building _tkinter without threads should be supported.

Does the above imply that this is a generic Unix as oppose to
Cygwin specific problem?


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 04:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-19 04:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 02:06:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 18:06:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 15:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Jason Tishler (jlt63)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

>Comment By: John Speno (corvus)
Date: 2003-03-26 21:06

Message:
Logged In: YES 
user_id=2138

It fails on MacOS X when made w/o threads. That's unix enough.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-26 17:59

Message:
Logged In: YES 
user_id=21627

This is my suspicion. I haven't tried building Python on a
Unix system without threads, but I suspect it fails as well.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-26 16:30

Message:
Logged In: YES 
user_id=86216

loewis> Building _tkinter without threads should be supported.

Does the above imply that this is a generic Unix as oppose to
Cygwin specific problem?


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 13:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-18 22:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-18 22:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 19:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 03:58:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 26 Mar 2003 19:58:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-707576 ] -i -u options give SyntaxError on Windows
Message-ID: 

Bugs item #707576, was opened at 2003-03-21 10:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Withers (fresh)
Assigned to: Tim Peters (tim_one)
Summary: -i -u options give SyntaxError on Windows

Initial Comment:
C:\>python -i -u
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.
>>> print 1
  File "", line 1
    print 1
           ^
SyntaxError: invalid syntax
>>>

...and this behaviour continues, no mater what
statement you enter.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-26 22:58

Message:
Logged In: YES 
user_id=31435

The only way on Windows is to open a file yourself in text 
mode with buffer size 0, and either write to it directly, or 
set sys.stdout to it.

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

Comment By: Chris Withers (fresh)
Date: 2003-03-26 12:05

Message:
Logged In: YES 
user_id=24723

-u     : unbuffered binary stdout and stderr (also
PYTHONUNBUFFERED=x)

Hmmm... never noticed the binary bit before. 
Is there any way to get unbuffered output without it being
binary?

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-21 11:30

Message:
Logged In: YES 
user_id=31435

Why do you call this a bug?  -u forces stdin into binary mode, 
and the Python grammar does not allow \r\n line endings in 
program text (it never has, BTW).  Program text has to come 
from a file opened in text mode on Windows, and what you're 
seeing here is the same as what you'd see if you did

f = open('some_python_program.py', 'rb')
exec f.read()

on Windows.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 09:18:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 01:18:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-710373 ] IDE stdin doesn't have readlines
Message-ID: 

Bugs item #710373, was opened at 2003-03-26 23:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710373&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE stdin doesn't have readlines

Initial Comment:
This was submitted by email by macrulezatsofthomedotnet. It looks reasonable, but please have a look too.

SimpleStdin doesn't provide a readlines method
	some scripts call sys.stdin.readlines(). the default stdin does not support this behaviour. I added it by copying and pasting the readlines method from StringIO, and adapting the indentation to fit. works beautifully: it asks the user for a line of input repeatedly until the user clicks 'Cancel'. not perfect UI, but it's something.

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

>Comment By: Just van Rossum (jvr)
Date: 2003-03-27 10:18

Message:
Logged In: YES 
user_id=92689

Hm, I find the stdin.readline() emulation already a big pain, and I'm hesitant to add an even uglier kludge to support readlines(). The IDE is simply not well suited for stdin-based scripts, they are _much_ better run from the command line. But: an actual patch might still make it in...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710373&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 09:20:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 01:20:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-710374 ] Raise IDE output window over splash screen on early crash
Message-ID: 

Bugs item #710374, was opened at 2003-03-26 23:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: Raise IDE output window over splash screen on early crash

Initial Comment:
This one was also submitted by macrulezatsofthomedotnet, but I'm not so sure about it. What do you think, would changing the DLOG resource for the splash screen have other, unforeseen side effects?
The effect of the change I would dearly like: how often have I cursed the %#$ spalsh screen being in front of the error message I would really love to see...

Sometimes the script short-circuits while Python IDE is starting
	actually, I haven't fixed that yet, but I did get around the problem of it preventing Python from starting (which is a problem because the user then cannot quit). I ResEdited the Python IDE and changed the 'DLOG' resource, such that the 'About' dialogue (the splash screen) is a window, rather than an actual dialogue. thus, when the  window appears (showing a traceback), it moves to the frontmost instead of remaining behind the splash where it can't be read.

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

>Comment By: Just van Rossum (jvr)
Date: 2003-03-27 10:20

Message:
Logged In: YES 
user_id=92689

Perhaps the splash screen stuff should be in a try/finally so it's guaranteed to get closed?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 17:14:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 09:14:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-705120 ] imap docs: s/criterium/criterion/
Message-ID: 

Bugs item #705120, was opened at 2003-03-17 19:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705120&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Pomraning (pilcrow)
Assigned to: Martin v. Löwis (loewis)
Summary: imap docs: s/criterium/criterion/

Initial Comment:
At least in English, the usually accepted singular of
"criteria"  is "criterion," not "criterium," which is
something else entirely.

Noticed in the imaplib docs and imaplib.py search()
docstring.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-27 18:14

Message:
Logged In: YES 
user_id=21627

Thanks for the report. Fixed in imaplib.py 1.61, libimaplib.tex 
1.24.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705120&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 20:55:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 12:55:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-710374 ] Raise IDE output window over splash screen on early crash
Message-ID: 

Bugs item #710374, was opened at 2003-03-26 23:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: Raise IDE output window over splash screen on early crash

Initial Comment:
This one was also submitted by macrulezatsofthomedotnet, but I'm not so sure about it. What do you think, would changing the DLOG resource for the splash screen have other, unforeseen side effects?
The effect of the change I would dearly like: how often have I cursed the %#$ spalsh screen being in front of the error message I would really love to see...

Sometimes the script short-circuits while Python IDE is starting
	actually, I haven't fixed that yet, but I did get around the problem of it preventing Python from starting (which is a problem because the user then cannot quit). I ResEdited the Python IDE and changed the 'DLOG' resource, such that the 'About' dialogue (the splash screen) is a window, rather than an actual dialogue. thus, when the  window appears (showing a traceback), it moves to the frontmost instead of remaining behind the splash where it can't be read.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-03-27 21:55

Message:
Logged In: YES 
user_id=45365

Much better idea!

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-27 10:20

Message:
Logged In: YES 
user_id=92689

Perhaps the splash screen stuff should be in a try/finally so it's guaranteed to get closed?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710374&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 20:54:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 12:54:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-21 09:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 07:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-06 02:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 10:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 21:30:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 13:30:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: 

Bugs item #711019, was opened at 2003-03-27 15:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Thu Mar 27 23:55:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 15:55:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-20 23:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 00:55

Message:
Logged In: YES 
user_id=21627

This gets more and more confusing. Include/Python.h does
include both  and . Can you find out why
it isn't included on your system?

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-27 21:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-05 16:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 00:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 00:42:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 16:42:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-21 09:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 11:42

Message:
Logged In: YES 
user_id=46639

Lots (possibly all) of the HAVE_*_H tests in configure are
failing:
    In file included from /usr/include/sys/wait.h:25,
                 from /usr/include/stdlib.h:22,
                 from configure:2876:
    /usr/include/sys/siginfo.h:204: field `__value' has
incomplete type

I think the offending bits of code in sys/siginfo.h are:

#if (!defined(_POSIX_C_SOURCE) && !defined(_XPG4_2)) || \
        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)

union sigval {
        int     sival_int;      /* integer value */
        void    *sival_ptr;     /* pointer value */
};

#else                           /* needed in siginfo_t
structure */

union __sigval {
        int     __sival_int;    /* integer value */
        void    *__sival_ptr;   /* pointer value */
};

#endif

[...]

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
                                        union sigval    __value;
#else
                                        union __sigval  __value;
#endif


Would  _POSIX_C_SOURCE be getting set to a value > 2, which
would break siginfo.h?

PS. This Solaris 2.6 machine isn't mine and I can't give
access to it.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 10:55

Message:
Logged In: YES 
user_id=21627

This gets more and more confusing. Include/Python.h does
include both  and . Can you find out why
it isn't included on your system?

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 07:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-06 02:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 10:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 01:03:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 17:03:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-20 23:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 02:03

Message:
Logged In: YES 
user_id=21627

Yes, _POSIX_C_SOURCE is defined as 200112L; together with
_XOPEN_SOURCE (600) and _XOPEN_SOURCE_EXTENDED (1).

Can you please locate the block that sets
define_xopen_source in configure and see whether setting
this to no helps?

It looks to me that Solaris 2.6 is quite broken in this
respect, but I would accept adding it to the list of
known-broken systems, along with a comment that explains how
precisely it breaks.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 01:42

Message:
Logged In: YES 
user_id=46639

Lots (possibly all) of the HAVE_*_H tests in configure are
failing:
    In file included from /usr/include/sys/wait.h:25,
                 from /usr/include/stdlib.h:22,
                 from configure:2876:
    /usr/include/sys/siginfo.h:204: field `__value' has
incomplete type

I think the offending bits of code in sys/siginfo.h are:

#if (!defined(_POSIX_C_SOURCE) && !defined(_XPG4_2)) || \
        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)

union sigval {
        int     sival_int;      /* integer value */
        void    *sival_ptr;     /* pointer value */
};

#else                           /* needed in siginfo_t
structure */

union __sigval {
        int     __sival_int;    /* integer value */
        void    *__sival_ptr;   /* pointer value */
};

#endif

[...]

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
                                        union sigval    __value;
#else
                                        union __sigval  __value;
#endif


Would  _POSIX_C_SOURCE be getting set to a value > 2, which
would break siginfo.h?

PS. This Solaris 2.6 machine isn't mine and I can't give
access to it.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 00:55

Message:
Logged In: YES 
user_id=21627

This gets more and more confusing. Include/Python.h does
include both  and . Can you find out why
it isn't included on your system?

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-27 21:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-05 16:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 00:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 01:49:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 17:49:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-21 09:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 12:49

Message:
Logged In: YES 
user_id=46639

That works. Hacking configure so it looks like the following
allows python to  build:
  case $ac_sys_system/$ac_sys_release in
    # On OpenBSD, select(2) is not available if
_XOPEN_SOURCE is defined,
    # even though select is a POSIX function. Reported by J.
Ribbens.
    SunOS/5.6 | OpenBSD/2.* | OpenBSD/3.[012])
      define_xopen_source=no;;
  esac

Test summary:
4 tests failed:
    test_iconv_codecs test_locale test_tarfile test_tempfile
33 tests skipped:
    test_aepack test_al test_bsddb test_bsddb3 test_bz2 test_cd
    test_cl test_crypt test_curses test_email_codecs
test_gdbm test_gl
    test_gzip test_imgfile test_linuxaudiodev test_macfs
    test_macostools test_mpz test_nis test_normalization
    test_ossaudiodev test_pep277 test_plistlib test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout
test_unicode_file
    test_winreg test_winsound test_zipfile test_zipimport
test_zlib
6 skips unexpected on sunos5:
    test_sunaudiodev test_bz2 test_unicode_file test_nis
test_crypt
    test_zipimport


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 12:03

Message:
Logged In: YES 
user_id=21627

Yes, _POSIX_C_SOURCE is defined as 200112L; together with
_XOPEN_SOURCE (600) and _XOPEN_SOURCE_EXTENDED (1).

Can you please locate the block that sets
define_xopen_source in configure and see whether setting
this to no helps?

It looks to me that Solaris 2.6 is quite broken in this
respect, but I would accept adding it to the list of
known-broken systems, along with a comment that explains how
precisely it breaks.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 11:42

Message:
Logged In: YES 
user_id=46639

Lots (possibly all) of the HAVE_*_H tests in configure are
failing:
    In file included from /usr/include/sys/wait.h:25,
                 from /usr/include/stdlib.h:22,
                 from configure:2876:
    /usr/include/sys/siginfo.h:204: field `__value' has
incomplete type

I think the offending bits of code in sys/siginfo.h are:

#if (!defined(_POSIX_C_SOURCE) && !defined(_XPG4_2)) || \
        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)

union sigval {
        int     sival_int;      /* integer value */
        void    *sival_ptr;     /* pointer value */
};

#else                           /* needed in siginfo_t
structure */

union __sigval {
        int     __sival_int;    /* integer value */
        void    *__sival_ptr;   /* pointer value */
};

#endif

[...]

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
                                        union sigval    __value;
#else
                                        union __sigval  __value;
#endif


Would  _POSIX_C_SOURCE be getting set to a value > 2, which
would break siginfo.h?

PS. This Solaris 2.6 machine isn't mine and I can't give
access to it.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 10:55

Message:
Logged In: YES 
user_id=21627

This gets more and more confusing. Include/Python.h does
include both  and . Can you find out why
it isn't included on your system?

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 07:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-06 02:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 10:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 07:20:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 27 Mar 2003 23:20:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-20 23:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
>Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 02:49

Message:
Logged In: YES 
user_id=46639

That works. Hacking configure so it looks like the following
allows python to  build:
  case $ac_sys_system/$ac_sys_release in
    # On OpenBSD, select(2) is not available if
_XOPEN_SOURCE is defined,
    # even though select is a POSIX function. Reported by J.
Ribbens.
    SunOS/5.6 | OpenBSD/2.* | OpenBSD/3.[012])
      define_xopen_source=no;;
  esac

Test summary:
4 tests failed:
    test_iconv_codecs test_locale test_tarfile test_tempfile
33 tests skipped:
    test_aepack test_al test_bsddb test_bsddb3 test_bz2 test_cd
    test_cl test_crypt test_curses test_email_codecs
test_gdbm test_gl
    test_gzip test_imgfile test_linuxaudiodev test_macfs
    test_macostools test_mpz test_nis test_normalization
    test_ossaudiodev test_pep277 test_plistlib test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout
test_unicode_file
    test_winreg test_winsound test_zipfile test_zipimport
test_zlib
6 skips unexpected on sunos5:
    test_sunaudiodev test_bz2 test_unicode_file test_nis
test_crypt
    test_zipimport


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 02:03

Message:
Logged In: YES 
user_id=21627

Yes, _POSIX_C_SOURCE is defined as 200112L; together with
_XOPEN_SOURCE (600) and _XOPEN_SOURCE_EXTENDED (1).

Can you please locate the block that sets
define_xopen_source in configure and see whether setting
this to no helps?

It looks to me that Solaris 2.6 is quite broken in this
respect, but I would accept adding it to the list of
known-broken systems, along with a comment that explains how
precisely it breaks.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 01:42

Message:
Logged In: YES 
user_id=46639

Lots (possibly all) of the HAVE_*_H tests in configure are
failing:
    In file included from /usr/include/sys/wait.h:25,
                 from /usr/include/stdlib.h:22,
                 from configure:2876:
    /usr/include/sys/siginfo.h:204: field `__value' has
incomplete type

I think the offending bits of code in sys/siginfo.h are:

#if (!defined(_POSIX_C_SOURCE) && !defined(_XPG4_2)) || \
        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)

union sigval {
        int     sival_int;      /* integer value */
        void    *sival_ptr;     /* pointer value */
};

#else                           /* needed in siginfo_t
structure */

union __sigval {
        int     __sival_int;    /* integer value */
        void    *__sival_ptr;   /* pointer value */
};

#endif

[...]

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
                                        union sigval    __value;
#else
                                        union __sigval  __value;
#endif


Would  _POSIX_C_SOURCE be getting set to a value > 2, which
would break siginfo.h?

PS. This Solaris 2.6 machine isn't mine and I can't give
access to it.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 00:55

Message:
Logged In: YES 
user_id=21627

This gets more and more confusing. Include/Python.h does
include both  and . Can you find out why
it isn't included on your system?

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-27 21:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-05 16:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 00:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 10:47:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 02:47:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-711268 ] A large block of commands after an "if" cannot be compiled
Message-ID: 

Bugs item #711268, was opened at 2003-03-28 11:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: A large block of commands after an "if" cannot be compiled

Initial Comment:
A Generated Python script Contains the code:
    if 1:
          file = bugreport.vim
          ... long list of commands ....

Executing this code with:
      exec cmds in globals(), globals()

Results in the error:
      SystemError: com_backpatch: offset too large

Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.

Possible solutions:
1.  When there is too much code, use another jump
statement that allows for a larger offset.
2.  Always use a jump statement with a large offset
3.  When "if 1" is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).

It looks like this bug exists in all versions of Python.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 17:52:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 09:52:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 11:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Jason Tishler (jlt63)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

>Comment By: Jason Tishler (jlt63)
Date: 2003-03-28 08:52

Message:
Logged In: YES 
user_id=86216

Given that this is most likely a generic Unix issue, I prefer
that someone better qualified to resolve this problem be
assigned.

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

Comment By: John Speno (corvus)
Date: 2003-03-26 17:06

Message:
Logged In: YES 
user_id=2138

It fails on MacOS X when made w/o threads. That's unix enough.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-26 13:59

Message:
Logged In: YES 
user_id=21627

This is my suspicion. I haven't tried building Python on a
Unix system without threads, but I suspect it fails as well.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-26 12:30

Message:
Logged In: YES 
user_id=86216

loewis> Building _tkinter without threads should be supported.

Does the above imply that this is a generic Unix as oppose to
Cygwin specific problem?


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 09:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-18 18:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-18 18:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-18 15:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 18:20:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 10:20:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-709733 ] PyWeakref_GetObject incorrectly documented
Message-ID: 

Bugs item #709733, was opened at 2003-03-25 14:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709733&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Stone (mbrierst)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyWeakref_GetObject incorrectly documented

Initial Comment:

It returns None, not NULL when the object has gone away.
I got burned by this.
A quick perusal of the code shows it to be true.
Doc patch attached.


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

>Comment By: Ka-Ping Yee (ping)
Date: 2003-03-28 10:20

Message:
Logged In: YES 
user_id=45338

Ok, fixed.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709733&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 18:59:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 10:59:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-690317 ] 2.3a2 build fails on Solaris: posixmodule
Message-ID: 

Bugs item #690317, was opened at 2003-02-20 23:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Martin v. Löwis (loewis)
Summary: 2.3a2 build fails on Solaris: posixmodule

Initial Comment:
gcc 2.95.2
SunOS 5.6 sparc

gcc  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include  -DPy_BUILD_CORE      -c
./Modules/posixmodule.c -o Modules/posixmodule.o

In file included from Include/stringobject.h:10,
                 from Include/Python.h:83,
                 from ./Modules/posixmodule.c:16:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include/stdarg.h:170:
warning                                                                                                          
: redefinition of `va_list'
/usr/include/stdio.h:90: warning: `va_list' previously
declared here
./Modules/posixmodule.c: In function `posix_access':
./Modules/posixmodule.c:1261: warning: implicit
declaration of function `access'
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1302: warning: implicit
declaration of function
`ttyname                                                                                                          
'

----      ---


                             f'
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:6443: warning: implicit
declaration of function
`confstr                                                                                                          
'
./Modules/posixmodule.c: In function `posix_sysconf':
./Modules/posixmodule.c:6985: warning: implicit
declaration of function
`sysconf                                                                                                          
'
./Modules/posixmodule.c: In function
`setup_confname_table':
./Modules/posixmodule.c:7024: warning: implicit
declaration of function `qsort'
make: *** [Modules/posixmodule.o] Error 1



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 19:59

Message:
Logged In: YES 
user_id=21627

I have committed a minimally different change as

configure 1.386
configure.in 1.397

I'll declare this issue closed; if further problems remain,
please open a separate report, or (better yet) submit a patch.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 02:49

Message:
Logged In: YES 
user_id=46639

That works. Hacking configure so it looks like the following
allows python to  build:
  case $ac_sys_system/$ac_sys_release in
    # On OpenBSD, select(2) is not available if
_XOPEN_SOURCE is defined,
    # even though select is a POSIX function. Reported by J.
Ribbens.
    SunOS/5.6 | OpenBSD/2.* | OpenBSD/3.[012])
      define_xopen_source=no;;
  esac

Test summary:
4 tests failed:
    test_iconv_codecs test_locale test_tarfile test_tempfile
33 tests skipped:
    test_aepack test_al test_bsddb test_bsddb3 test_bz2 test_cd
    test_cl test_crypt test_curses test_email_codecs
test_gdbm test_gl
    test_gzip test_imgfile test_linuxaudiodev test_macfs
    test_macostools test_mpz test_nis test_normalization
    test_ossaudiodev test_pep277 test_plistlib test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout
test_unicode_file
    test_winreg test_winsound test_zipfile test_zipimport
test_zlib
6 skips unexpected on sunos5:
    test_sunaudiodev test_bz2 test_unicode_file test_nis
test_crypt
    test_zipimport


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 02:03

Message:
Logged In: YES 
user_id=21627

Yes, _POSIX_C_SOURCE is defined as 200112L; together with
_XOPEN_SOURCE (600) and _XOPEN_SOURCE_EXTENDED (1).

Can you please locate the block that sets
define_xopen_source in configure and see whether setting
this to no helps?

It looks to me that Solaris 2.6 is quite broken in this
respect, but I would accept adding it to the list of
known-broken systems, along with a comment that explains how
precisely it breaks.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-28 01:42

Message:
Logged In: YES 
user_id=46639

Lots (possibly all) of the HAVE_*_H tests in configure are
failing:
    In file included from /usr/include/sys/wait.h:25,
                 from /usr/include/stdlib.h:22,
                 from configure:2876:
    /usr/include/sys/siginfo.h:204: field `__value' has
incomplete type

I think the offending bits of code in sys/siginfo.h are:

#if (!defined(_POSIX_C_SOURCE) && !defined(_XPG4_2)) || \
        (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__)

union sigval {
        int     sival_int;      /* integer value */
        void    *sival_ptr;     /* pointer value */
};

#else                           /* needed in siginfo_t
structure */

union __sigval {
        int     __sival_int;    /* integer value */
        void    *__sival_ptr;   /* pointer value */
};

#endif

[...]

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
                                        union sigval    __value;
#else
                                        union __sigval  __value;
#endif


Would  _POSIX_C_SOURCE be getting set to a value > 2, which
would break siginfo.h?

PS. This Solaris 2.6 machine isn't mine and I can't give
access to it.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 00:55

Message:
Logged In: YES 
user_id=21627

This gets more and more confusing. Include/Python.h does
include both  and . Can you find out why
it isn't included on your system?

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-03-27 21:54

Message:
Logged In: YES 
user_id=46639

Adding a #include  Fixes the following:

./Modules/posixmodule.c: In function `posix_fchdir':
./Modules/posixmodule.c:1200: `fchdir' undeclared (first use
in this function)
./Modules/posixmodule.c:1200: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:1200: for each function it appears in.)
./Modules/posixmodule.c: In function `posix_chroot':
./Modules/posixmodule.c:1237: `chroot' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fsync':
./Modules/posixmodule.c:1249: `fsync' undeclared (first use
in this function)
./Modules/posixmodule.c: In function `posix_fdatasync':
./Modules/posixmodule.c:1267: `fdatasync' undeclared (first
use in this function

Adding #include  fixes the following:
./Modules/posixmodule.c: In function `posix_system':
./Modules/posixmodule.c:1868: warning: implicit declaration
of function `system'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2110: warning: implicit declaration
of function `malloc'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2613: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2632: warning: function declaration
isn't a prototype
./Modules/posixmodule.c:2634: warning: implicit declaration
of function `grantpt'
./Modules/posixmodule.c:2639: warning: implicit declaration
of function `unlockpt'
./Modules/posixmodule.c: In function `posix_putenv':
./Modules/posixmodule.c:5486: warning: implicit declaration
of function `putenv'
./Modules/posixmodule.c: In function `posix_tempnam':
./Modules/posixmodule.c:5917: warning: implicit declaration
of function `free'
./Modules/posixmodule.c: In function `setup_confname_table':
./Modules/posixmodule.c:6903: warning: implicit declaration
of function `qsort'

Changing line 187 from:
extern char *getcwd(char *, int);
to:
extern char *getcwd(char *, size_t);

And everything builds happily.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-05 16:40

Message:
Logged In: YES 
user_id=21627

I find several things confusing in this report:

- why is va_list redefined? To my knowledge, gcc 2.95.2
supports Solaris 2.6 correctly, so it shouldn't provide a
conflicting va_list definition. The typical cause is that
the gcc installation doesn't match the operating system
version (i.e. fixincludes was run for different headers).
Since the gcc installation appears to have been built for
2.6, I infer that the system being used might not be Solaris
2.6.

- All the problems reported are warnings, which don't cause
compilation to fail. What is the actual error (use -w to
suppress all warnings).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-21 00:08

Message:
Logged In: YES 
user_id=33168

Jeff, I don't know if anyone has access to Solaris 5.6.  Can
you provide a patch to get posixmodule to compile?  From the
bug report, I only see warnings, not an actual error which
is breaking the build.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690317&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 19:13:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 11:13:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-711268 ] A large block of commands after an "if" cannot be compiled
Message-ID: 

Bugs item #711268, was opened at 2003-03-28 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
>Summary: A large block of commands after an "if" cannot be compiled

Initial Comment:
A Generated Python script Contains the code:
    if 1:
          file = bugreport.vim
          ... long list of commands ....

Executing this code with:
      exec cmds in globals(), globals()

Results in the error:
      SystemError: com_backpatch: offset too large

Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.

Possible solutions:
1.  When there is too much code, use another jump
statement that allows for a larger offset.
2.  Always use a jump statement with a large offset
3.  When "if 1" is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).

It looks like this bug exists in all versions of Python.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:13

Message:
Logged In: YES 
user_id=6380

Just curious. How big was the block of code?

Also, I wonder if the error message is bogus; opcode
arguments can now be 32 bits AFAIK.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 19:18:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 11:18:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-711268 ] A large block of commands after an "if" cannot be compiled
Message-ID: 

Bugs item #711268, was opened at 2003-03-28 05:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
>Summary: A large block of commands after an "if" cannot be compiled

Initial Comment:
A Generated Python script Contains the code:
    if 1:
          file = bugreport.vim
          ... long list of commands ....

Executing this code with:
      exec cmds in globals(), globals()

Results in the error:
      SystemError: com_backpatch: offset too large

Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.

Possible solutions:
1.  When there is too much code, use another jump
statement that allows for a larger offset.
2.  Always use a jump statement with a large offset
3.  When "if 1" is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).

It looks like this bug exists in all versions of Python.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:18

Message:
Logged In: YES 
user_id=6380

Hm, the 32-bit argument doesn't work because of what
backpatch does. It would require a totally different
approach to allow backpatching a larer offset, or we'd
always have to reserve 4 bytes for the offset. :-(

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:13

Message:
Logged In: YES 
user_id=6380

Just curious. How big was the block of code?

Also, I wonder if the error message is bogus; opcode
arguments can now be 32 bits AFAIK.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 19:20:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 11:20:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: 

Bugs item #711019, was opened at 2003-03-27 16:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Tim Peters (tim_one)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 19:21:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 11:21:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-710197 ] initialisation problem with dict.fromkeys()
Message-ID: 

Bugs item #710197, was opened at 2003-03-26 12:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470

Category: None
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Frederic Sohm (fsms)
Assigned to: Nobody/Anonymous (nobody)
Summary: initialisation problem with dict.fromkeys()

Initial Comment:
I have a problem of initialization of dictionary with the new method  
dict.fromkeys(sequence [, defaults]) when defaults is a list.  
  
here an example :  
  
Python 2.3a2 (#1, Feb 21 2003, 14:28:59)   
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2  
Type "copyright", "credits" or "license" for more information.  
IDLEfork 0.9a2  
>>> a = {}.fromkeys([0, 1], [ ])  
>>> a[0]  
[ ]  
>>> a[1]  
[ ]  
>>> a[0] += [2]  
>>> a[0]  
[2]  
>>> a[1]  
[2]  
>>> a[1] is a[0]  
True  
>>> a[0].append(3)  
>>> a[0]  
[2, 3]  
>>> a[1]  
[2, 3]  
etc... same thing if I use list() instead of [ ] 
  
the same list seems to be assigned to all the keys.  
when using string, tuple... it is normal (or what I would expect at 
least) : 
>>> b = {}.fromkeys([0,1], '') 
>>> b[0] 
'' 
>>> b[1] 
'' 
>>> b[0] += '2' 
>>> b[0] 
'2' 
>>> b[1] 
'' 
>>>b[0] is b[1] 
False 

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:21

Message:
Logged In: YES 
user_id=6380

This is not a bug but a simple aliasing problem; all keys
will share the same *object* for their initial value.

Write help@python.org or post to comp.lang.python if you
want to learn more.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 19:25:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 11:25:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-709428 ] os.altsep is None under Windows
Message-ID: 

Bugs item #709428, was opened at 2003-03-25 08:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.altsep is None under Windows

Initial Comment:
With both 2.3a2 and 2.22, os.altsep is None under 
Windows.  This does not match the documentation, 
which states (in part): 'This is set to "/" on Windows 
systems where sep is a backslash.'  (Perhaps this is a 
documentation bug.)


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:25

Message:
Logged In: YES 
user_id=6380

Not a doc bug. This seems to have been lost somehow!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 19:27:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 11:27:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-709428 ] os.altsep is None under Windows
Message-ID: 

Bugs item #709428, was opened at 2003-03-25 08:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Greg Chapman (glchapman)
>Assigned to: Skip Montanaro (montanaro)
Summary: os.altsep is None under Windows

Initial Comment:
With both 2.3a2 and 2.22, os.altsep is None under 
Windows.  This does not match the documentation, 
which states (in part): 'This is set to "/" on Windows 
systems where sep is a backslash.'  (Perhaps this is a 
documentation bug.)


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:27

Message:
Logged In: YES 
user_id=6380

Skip, I think you might know more about this?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:25

Message:
Logged In: YES 
user_id=6380

Not a doc bug. This seems to have been lost somehow!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 20:03:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 12:03:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-711268 ] A large block of commands after an "if" cannot be compiled
Message-ID: 

Bugs item #711268, was opened at 2003-03-28 11:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
>Summary: A large block of commands after an "if" cannot be compiled

Initial Comment:
A Generated Python script Contains the code:
    if 1:
          file = bugreport.vim
          ... long list of commands ....

Executing this code with:
      exec cmds in globals(), globals()

Results in the error:
      SystemError: com_backpatch: offset too large

Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.

Possible solutions:
1.  When there is too much code, use another jump
statement that allows for a larger offset.
2.  Always use a jump statement with a large offset
3.  When "if 1" is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).

It looks like this bug exists in all versions of Python.

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

>Comment By: Bram Moolenaar (vimboss)
Date: 2003-03-28 21:03

Message:
Logged In: YES 
user_id=57665

I can reproduce the problem with this text:
if 1:
   a = "a"

Repeat the assignment 7282 times.  Feed this text to "exec".
With 7281 assignments you do not get the error.
Looks like 9 bytes are produced per assignment.

Good luck fixing this!

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 20:18

Message:
Logged In: YES 
user_id=6380

Hm, the 32-bit argument doesn't work because of what
backpatch does. It would require a totally different
approach to allow backpatching a larer offset, or we'd
always have to reserve 4 bytes for the offset. :-(

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 20:13

Message:
Logged In: YES 
user_id=6380

Just curious. How big was the block of code?

Also, I wonder if the error message is bogus; opcode
arguments can now be 32 bits AFAIK.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 20:05:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 12:05:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 21:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Speno (corvus)
>Assigned to: Nobody/Anonymous (nobody)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-28 18:52

Message:
Logged In: YES 
user_id=86216

Given that this is most likely a generic Unix issue, I prefer
that someone better qualified to resolve this problem be
assigned.

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

Comment By: John Speno (corvus)
Date: 2003-03-27 03:06

Message:
Logged In: YES 
user_id=2138

It fails on MacOS X when made w/o threads. That's unix enough.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-26 23:59

Message:
Logged In: YES 
user_id=21627

This is my suspicion. I haven't tried building Python on a
Unix system without threads, but I suspect it fails as well.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-26 22:30

Message:
Logged In: YES 
user_id=86216

loewis> Building _tkinter without threads should be supported.

Does the above imply that this is a generic Unix as oppose to
Cygwin specific problem?


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 04:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-19 04:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 22:46:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 14:46:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 20:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 23:46

Message:
Logged In: YES 
user_id=21627

Can you provide a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 22:48:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 14:48:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-709428 ] os.altsep is None under Windows
Message-ID: 

Bugs item #709428, was opened at 2003-03-25 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Greg Chapman (glchapman)
Assigned to: Skip Montanaro (montanaro)
Summary: os.altsep is None under Windows

Initial Comment:
With both 2.3a2 and 2.22, os.altsep is None under 
Windows.  This does not match the documentation, 
which states (in part): 'This is set to "/" on Windows 
systems where sep is a backslash.'  (Perhaps this is a 
documentation bug.)


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 16:48

Message:
Logged In: YES 
user_id=44345

checked in as ntpath.py v 1.57 - also backported to 2.2 branch 
(os.py 1.50.8.7). altsep on Windows was None before I migrated stuff to 
ntpath.py.  I don't think it was ever not None on Windows.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 13:27

Message:
Logged In: YES 
user_id=6380

Skip, I think you might know more about this?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 13:25

Message:
Logged In: YES 
user_id=6380

Not a doc bug. This seems to have been lost somehow!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 22:50:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 14:50:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-711019 ] math.log(0) differs from math.log(0L)
Message-ID: 

Bugs item #711019, was opened at 2003-03-27 15:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: math.log(0) differs from math.log(0L)

Initial Comment:
This is maybe a minor nit, but math.log(0) raises an OverflowError
(range error) while math.log(0L) raises a ValueError (domain error).
Seems to me they ought to behave the same.  I noticed this in
2.2.2 but it's present in CVS.  In 2.1, both return -Inf.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 16:50

Message:
Logged In: YES 
user_id=44345

Ack!  I realized this is probably platform-dependent.  The results I
reported on were for Mac OS X.  Here's a little table of everything I could
quickly get my hands on.

Platform                Python Version  math.log(0)     math.log(0L)
Mac OS X                2.1.3           -Inf            -Inf
Mac OS X                2.2.2           OverflowError   ValueError
Mac OS X                CVS             OverflowError   ValueError
Win2k/MSVC              2.2.2           OverflowError   ValueError
Win2k/MSVC              2.3a2           OverflowError   ValueError
Win2k/cygwin            2.2.2           ValueError      ValueError
Solaris/gcc 2.95.2      2.3a2+          OverflowError   ValueError

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711019&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 23:12:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 15:12:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 10:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

>Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-28 14:12

Message:
Logged In: YES 
user_id=119770

Ok, try this patch. The first one didn't change all the
files. Tested on HP-UX 11i (11.11) and Tru64 UNIX 5.1.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 13:46

Message:
Logged In: YES 
user_id=21627

Can you provide a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 23:15:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 15:15:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 10:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

>Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-28 14:15

Message:
Logged In: YES 
user_id=119770

Ok, let's try this again.

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-28 14:12

Message:
Logged In: YES 
user_id=119770

Ok, try this patch. The first one didn't change all the
files. Tested on HP-UX 11i (11.11) and Tru64 UNIX 5.1.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 13:46

Message:
Logged In: YES 
user_id=21627

Can you provide a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 23:16:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 15:16:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 10:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

>Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-28 14:16

Message:
Logged In: YES 
user_id=119770

Ok, file upload sucks. Try:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.2.2-710285

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-28 14:15

Message:
Logged In: YES 
user_id=119770

Ok, let's try this again.

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-28 14:12

Message:
Logged In: YES 
user_id=119770

Ok, try this patch. The first one didn't change all the
files. Tested on HP-UX 11i (11.11) and Tru64 UNIX 5.1.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 13:46

Message:
Logged In: YES 
user_id=21627

Can you provide a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Fri Mar 28 23:21:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 15:21:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 20:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
>Assigned to: Martin v. Löwis (loewis)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-29 00:16

Message:
Logged In: YES 
user_id=119770

Ok, file upload sucks. Try:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.2.2-710285

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-29 00:15

Message:
Logged In: YES 
user_id=119770

Ok, let's try this again.

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-29 00:12

Message:
Logged In: YES 
user_id=119770

Ok, try this patch. The first one didn't change all the
files. Tested on HP-UX 11i (11.11) and Tru64 UNIX 5.1.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 23:46

Message:
Logged In: YES 
user_id=21627

Can you provide a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 00:26:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 16:26:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-711632 ] htmllib.HTMLParser.anchorlist problem
Message-ID: 

Bugs item #711632, was opened at 2003-03-28 19:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711632&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Gray (cpgray)
Assigned to: Nobody/Anonymous (nobody)
Summary: htmllib.HTMLParser.anchorlist problem

Initial Comment:
htmllib.HTMLParser.anchorlist is cleared when
__init__() is called but not when reset() is called. 
Processing more than one document with the same
instance accumulates anchors from all documents
processed in the list.

Arguably a feature not a bug, but it makes sense for
reset to clear whatever is initialized by __init__.

Here is an illustrative IDLE session:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more
information.
IDLE 0.8 -- press F1 for help
>>> import htmllib
>>> import formatter
>>> p = htmllib.HTMLParser(formatter.NullFormatter())
>>> p.feed('Python')
>>> p.anchorlist
['http://www.python.org']
>>> p.reset()
>>> p.feed('Sourceforge')
>>> p.anchorlist
['http://www.python.org', 'http://sourceforge.net/']

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711632&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 01:00:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 28 Mar 2003 17:00:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-709428 ] os.altsep is None under Windows
Message-ID: 

Bugs item #709428, was opened at 2003-03-25 08:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Greg Chapman (glchapman)
Assigned to: Skip Montanaro (montanaro)
Summary: os.altsep is None under Windows

Initial Comment:
With both 2.3a2 and 2.22, os.altsep is None under 
Windows.  This does not match the documentation, 
which states (in part): 'This is set to "/" on Windows 
systems where sep is a backslash.'  (Perhaps this is a 
documentation bug.)


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 20:00

Message:
Logged In: YES 
user_id=6380

How strange.  It was my intention for it to be '/' but
somehow it didn't get set. Thanks!

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-28 17:48

Message:
Logged In: YES 
user_id=44345

checked in as ntpath.py v 1.57 - also backported to 2.2 branch 
(os.py 1.50.8.7). altsep on Windows was None before I migrated stuff to 
ntpath.py.  I don't think it was ever not None on Windows.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:27

Message:
Logged In: YES 
user_id=6380

Skip, I think you might know more about this?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 14:25

Message:
Logged In: YES 
user_id=6380

Not a doc bug. This seems to have been lost somehow!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709428&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 10:02:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 02:02:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-698517 ] Tk 8.4.2 and Tkinter.py _substitue function
Message-ID: 

Bugs item #698517, was opened at 2003-03-06 06:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698517&group_id=5470

Category: Tkinter
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Martin v. Löwis (loewis)
Summary: Tk 8.4.2 and Tkinter.py _substitue function

Initial Comment:
In Tk 8.4.2 (out now, or RSN), a change was made to events. From Tk's ChangeLog:

        * generic/tkBind.c (ExpandPercents): Only allow events to see
        those expansions that are actually valid for them, and force the
        substitution of the rest as "??".  This stops some crashes on
        Windows and gets rid of bogus values everywhere.  [Bug #612110]

Thus, Tkinter.py's _substitue method of Class Misc will need all of it's called to getint() (aka int()) wrapped to catch ValueErrors because the argument could now be '??' instead of something int()'able.

Does that make sense?

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:02

Message:
Logged In: YES 
user_id=21627

Fixed with patch #707701

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698517&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 10:21:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 02:21:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-710285 ] Rename definition of LONG_LONG
Message-ID: 

Bugs item #710285, was opened at 2003-03-26 20:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Martin v. Löwis (loewis)
Summary: Rename definition of LONG_LONG

Initial Comment:
Can we rename the LONG_LONG definition in longobject.h
and pyport.h to PY_LONG_LONG or some other name? It
causes problems on HP-UX with the HP C++ compiler:
http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0303/0100.html

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:21

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. I have applied it as

utilities.tex 1.9
longobject.h 2.29
pyport.h 2.60
_testcapimodule.c 1.20
addrinfo.h 1.5
bz2module.c 1.16
posixmodule.c 2.294
resource.c 2.29
socketmodule.c 1.258
structmodule.c 2.60
longobject.c 1.157
pyconfig.h 1.19
getargs.c 2.97
modsupport.c 2.66
NEWS 1.704

I won't backport it to 2.2, as it may break existing
extension modules.

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-29 00:16

Message:
Logged In: YES 
user_id=119770

Ok, file upload sucks. Try:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.2.2-710285

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-29 00:15

Message:
Logged In: YES 
user_id=119770

Ok, let's try this again.

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

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-03-29 00:12

Message:
Logged In: YES 
user_id=119770

Ok, try this patch. The first one didn't change all the
files. Tested on HP-UX 11i (11.11) and Tru64 UNIX 5.1.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-28 23:46

Message:
Logged In: YES 
user_id=21627

Can you provide a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710285&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 15:03:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 07:03:55 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-507262 ] GNU --option syntax not supported
Message-ID: 

Feature Requests item #507262, was opened at 2002-01-23 00:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=507262&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 2
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: GNU --option syntax not supported

Initial Comment:
It would be good if the python interpreter 
supported standard GNU --log style options as
well.

Jari

//root@W2KPICASSO /usr/bin $ python -V
Python 2.2
//root@W2KPICASSO /usr/bin $ python --help
Unknown option: --
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Try `python -h' for more information.
//root@W2KPICASSO /usr/bin $ python -h    
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Options and arguments (and corresponding environment 
variables):
-c cmd : program passed in as string (terminates 
option list)
-d     : debug output from parser (also PYTHONDEBUG=x)
-E     : ignore environment variables (such as 
PYTHONPATH)
-h     : print this help message and exit
-i     : inspect interactively after running script, 
(also PYTHONINSPECT=x)
         and force prompts, even if stdin does not 
appear to be a terminal
-O     : optimize generated bytecode (a tad; also 
PYTHONOPTIMIZE=x)
-OO    : remove doc-strings in addition to the -O 
optimizations
-Q arg : division options: -Qold (default), -Qwarn, -
Qwarnall, -Qnew
-S     : don't imply 'import site' on initialization
-t     : issue warnings about inconsistent tab usage (-
tt: issue errors)
-u     : unbuffered binary stdout and stderr (also 
PYTHONUNBUFFERED=x)
-U     : Unicode literals: treats '...' literals like 
u'...'
-v     : verbose (trace import statements) (also 
PYTHONVERBOSE=x)
-V     : print the Python version number and exit
-W arg : warning control (arg is 
action:message:category:module:lineno)
-x     : skip first line of source, allowing use of 
non-Unix forms of #!cmd
file   : program read from script file
-      : program read from stdin (default; interactive 
mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup 
(no default)
PYTHONPATH   : ':'-separated list of directories 
prefixed to the
               default module search path.  The result 
is sys.path.
PYTHONHOME   : alternate  directory (or 
:).
               The default module search path uses 
/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements 
(Windows).


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:03

Message:
Logged In: YES 
user_id=21627

In Python 2.3, getopt supports gnu_getopt, so this feature
is now implemented.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 23:00

Message:
Logged In: YES 
user_id=21627

Moved to the feature requests tracker.

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

Comment By: Jari Aalto (jaalto)
Date: 2002-03-10 09:02

Message:
Logged In: YES 
user_id=65014


Sorry for the typo: I meant "GNU 'long' style options",
it would be good if there were legible options like

-h  => --help

Although Python is not GNU program, the "--long" style
option usage is "de facto" accepted in almost everywhere.

I would see it a good addition to Python.




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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-09 15:03

Message:
Logged In: YES 
user_id=6380

Rather than quoting the Python -h output (with which I am
quite familiar, thank you!), you could explain what --log is
supposed to do. What does it do and why do you want it? (BTW
Python is not GNU software.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=507262&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 15:05:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 07:05:44 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706970 ] Including python-codecs codecs in standard distribution?
Message-ID: 

Feature Requests item #706970, was opened at 2003-03-20 17:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Stabell (bjoerns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Including python-codecs codecs in standard distribution?

Initial Comment:
Are there any plans to include the python-codecs in the 
standard distribution?  They are Chinese and Japanese 
encodings, very useful if you live in China or Japan, 
which quite a few people do :)  -- Imagine having to 
download ASCII encoding separately.

What's stopping the inclusion, if anything?

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:05

Message:
Logged In: YES 
user_id=21627

The size of the code, and its correctness is stopping
inclusion of these codecs.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 15:08:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 07:08:48 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: 

Feature Requests item #706392, was opened at 2003-03-19 18:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 15:13:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 07:13:43 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-694320 ] Add list.join()
Message-ID: 

Feature Requests item #694320, was opened at 2003-02-27 13:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694320&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel (kamek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add list.join()

Initial Comment:
While there's string.join(list), I believe it'd make much 
more sense to have list.join(string). In most languages 
(and also in the string module), the first argument for join 
functions is the list, and the second is the separator. 
Not to mention code using methods directly in strings, 
like "' '.join(...)" is uglier :)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:13

Message:
Logged In: YES 
user_id=21627

This has been discussed many times, and each time the
conclusion was that the idea is flawed, as it would require
adding join operations not only to lists, but to all
sequences. For example, Python currently supports

>>> "u".join("Hallo")
'Huaululuo'



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694320&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 15:14:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 07:14:27 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py
Message-ID: 

Feature Requests item #494854, was opened at 2001-12-19 02:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: M.-A. Lemburg (lemburg)
Summary: add platform.py

Initial Comment:
Here's a request to add Marc-Andre Lemburg's
platform.py to the Python standard library.

It provides more complete platform information
than either sys.platform or
distutils.util.get_platform()

For more info, see:
http://www.lemburg.com/files/python/platform.py


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:14

Message:
Logged In: YES 
user_id=21627

Is there any hope of getting documentation?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-05 17:51

Message:
Logged In: YES 
user_id=38388

Guido has already approved the addition; so it's basically
just the docs that are currently missing...

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-19 10:27

Message:
Logged In: YES 
user_id=38388

No problem from here :-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 15:54:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 07:54:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2
Message-ID: 

Bugs item #711830, was opened at 2003-03-29 10:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: SEEK_{SET,CUR,END} missing in 2.2.2

Initial Comment:
Python 1.5.2 used to define SEEK_{SET,CUR,END} both in
FCNTL.py and in posixfile.py

Python 2.2.2 obsoletes both of them (and the symbols
are no longer in FCNTL anyway).

A quick grep on the 2.2.2 tree shows me posixfile is
the only place that still defines the SEEK_* constants.
It seems to me it's wrong to drop the constants
(because a deprecated module will eventually be dropped).

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 17:16:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 09:16:39 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: 

Feature Requests item #706392, was opened at 2003-03-19 11:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 11:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 09:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 17:32:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 09:32:28 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706970 ] Including python-codecs codecs in standard distribution?
Message-ID: 

Feature Requests item #706970, was opened at 2003-03-20 11:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Stabell (bjoerns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Including python-codecs codecs in standard distribution?

Initial Comment:
Are there any plans to include the python-codecs in the 
standard distribution?  They are Chinese and Japanese 
encodings, very useful if you live in China or Japan, 
which quite a few people do :)  -- Imagine having to 
download ASCII encoding separately.

What's stopping the inclusion, if anything?

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-29 12:32

Message:
Logged In: YES 
user_id=12800

We should continue to discuss this.  There are good technical and political reasons for re-evaluating whether to include Asian codecs in a batteries included Python distribution.

I suggest python-dev and/or i18n-sig @python.org.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 10:05

Message:
Logged In: YES 
user_id=21627

The size of the code, and its correctness is stopping
inclusion of these codecs.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 17:35:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 09:35:08 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: 

Feature Requests item #706392, was opened at 2003-03-19 18:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 18:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 18:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 16:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 17:36:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 09:36:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2
Message-ID: 

Bugs item #711830, was opened at 2003-03-29 16:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: SEEK_{SET,CUR,END} missing in 2.2.2

Initial Comment:
Python 1.5.2 used to define SEEK_{SET,CUR,END} both in
FCNTL.py and in posixfile.py

Python 2.2.2 obsoletes both of them (and the symbols
are no longer in FCNTL anyway).

A quick grep on the 2.2.2 tree shows me posixfile is
the only place that still defines the SEEK_* constants.
It seems to me it's wrong to drop the constants
(because a deprecated module will eventually be dropped).

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 18:36

Message:
Logged In: YES 
user_id=21627

Would you agree that these constants are best located in the
os module?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 21:55:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 13:55:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 10:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 16:55

Message:
Logged In: YES 
user_id=33168

This means the iconv_open() call is failing.  Unless you
know you need this module, you probably don't.  And if you
do need this module, you probably know more than I do. :-) 
So if you are just trying to get this working, I don't think
it's a big deal.  It seems to work on some HPUX machines.  I
suspect the reason the iconv_open() is failing is because of
a configuration on your machine.  This call is for
translating character sets.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 11:26

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I edited Modules/Setup line 483 like this:

_iconv_codec _iconv_codec.c -I/usr/include

I can now build Python! 

However test_iconv_codecs fails:

capulet:dist/src 
> ./python ./Lib/test/test_iconv_codecs.py
Traceback (most recent call last):
  File "./Lib/test/test_iconv_codecs.py", line 3, in ?
    import codecs, _iconv_codec
RuntimeError: can't initialize the _iconv_codec module: 
iconv_open() failed


I tried adding '-l:libdld.sl' to line 483 (as suggested by 
the man page) but
the test still fails.



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 09:43

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I have now discovered that there is a different version of 
iconv.h on my workstation in /usr/local/include.

It appears to be part of the zlib package and it contains 
the pre-processor macros which are converting the 
iconv statements to libiconv.

It is being used instead of the one in /usr/include, 
because the compile command contains 
-I/usr/local/include 

Is there any easy to prevent this path from being added 
to the compile commands? 



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-25 12:51

Message:
Logged In: YES 
user_id=200117

Neal,

The original error referred to unresolved 
symbol 'libiconv_open'.

The source module _iconv_codec.c contains calls to 
iconv_open(), not libiconv_open().

However, if I recompile it with the -E flag there is a pre-
processor substitution happening which is converting 
all instances of 'iconv' to 'libiconv'

Here I grepped the pre-processor output for 'iconv'...

extern int _libiconv_version;
typedef void* libiconv_t ;
extern libiconv_t  libiconv_open  (const char* tocode, 
const char* fromcode);
extern size_t libiconv  (libiconv_t  cd,  char* * inbuf, 
size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
extern int libiconv_close  (libiconv_t  cd);
extern int libiconvctl  (libiconv_t  cd, int request, void* 
argument);
    libiconv_t   enchdl, dechdl;
        if (libiconv (self->enchdl, (char**)&inp, &inplen, 
&out, &outlen)
        size_t res = libiconv (self->dechdl, (char**)&inp, 
&inplen, &out, &outlen);
    new->enchdl = new->dechdl = (libiconv_t )(-1);
    new->dechdl = libiconv_open ("ucs-2-internal" , 
new->encoding);
    if (new->dechdl == (libiconv_t )(-1)) {
    new->enchdl = libiconv_open (new->encoding, "ucs-
2-internal" );
    if (new->enchdl == (libiconv_t )(-1)) {
        libiconv_close (new->dechdl);
        new->dechdl = (libiconv_t )(-1);
    if (self->enchdl != (libiconv_t )-1)
        libiconv_close (self->enchdl);
    if (self->dechdl != (libiconv_t )-1)
        libiconv_close (self->dechdl);
    libiconv_t  hdl = libiconv_open ("ucs-2-
internal" , "ISO-8859-1");
    if (hdl == (libiconv_t )-1) {
    res = libiconv (hdl, &inptr, &insize, &outptr, &outsize);
        libiconv_close (hdl);
    libiconv_close (hdl);

Is this supposed to be happening??

If not, what could be causing it??



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:52

Message:
Logged In: YES 
user_id=33168

Looking further into the python configure, I see that the
option is --with-dl-dld, however, this option is not
supported.  Can try to play with the build options to find
the magic that works on your version of HPUX?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 10:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 12:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 17:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 04:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 12:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-27 22:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 22:32:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 14:32:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-711967 ] Lookup of Mac error string can mess up resfile chain
Message-ID: 

Bugs item #711967, was opened at 2003-03-29 23:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711967&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Lookup of Mac error string can mess up resfile chain

Initial Comment:
Looking up a Mac error string may open a resource file, and the resource file chain isn't reset correctly afterwards. This may mess up code that uses Get1Resource and friends.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711967&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 22:55:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 14:55:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 13:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 17:55

Message:
Logged In: YES 
user_id=33168

This works for me on linux.  I don't know if there's any
issue wrt to removing _needwrapper.  Perhaps it should be
checked in and see if anyone complains?  I'm not sure who
else should review this patch.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-24 12:23

Message:
Logged In: YES 
user_id=44345

Jack, Any chance you can simply apply it to the source and see how it goes
on MacOS9? -Skip

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-24 05:58

Message:
Logged In: YES 
user_id=45365

If this patch is accepted: may I request it be done soon? Changes like this often affect how things work on MacOS9 (IOW: break things on MacOS9:-), and in general changing the makefile() semantics on all non-windows platforms is something that may turn up hidden bugs, so I don't think we want this in as a last-second mod before 2.3b1 goes out.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 13:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 23:19:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 15:19:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-711986 ] gensuitemodule needs to be documented
Message-ID: 

Bugs item #711986, was opened at 2003-03-30 00:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711986&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: gensuitemodule needs to be documented

Initial Comment:
Gensuitemodule is now in the library, and it needs to be documented. Also, the old documentation in Mac/Demo probably needs an update.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711986&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 23:25:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 15:25:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-711989 ] IDE textwindow scrollbar is over-enthusiastic
Message-ID: 

Bugs item #711989, was opened at 2003-03-30 00:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711989&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE textwindow scrollbar is over-enthusiastic

Initial Comment:
In text windows (only in text windows, I think) the scrollbar-repeat is over-enthusiastic in its repeat behavior. At least: under OSX it is. No matter how short I click in the up/down arrows (or the pageup/pagedown areas) I never seem able to scroll only a single line or page, always at least two.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711989&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 23:33:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 15:33:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-711991 ] IDE needs easy access to builtin help()
Message-ID: 

Bugs item #711991, was opened at 2003-03-30 00:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711991&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE needs easy access to builtin help()

Initial Comment:
Just, I'm assigning this to you for feedback. Feel free to assign back after providing it.

I think we need access to the help()-style documentation in the IDE, especially when browsing objects and such it would be very helpful.

What I'm thinking of at the moment is a window called "Help for Selection" (any better ideas?), and if that window is opened it will display the help() text for the current selection. It would follow focus, i.e. when you select a different window or a different object in the same window it would change.

An alternative design would be that you would have to use a command "Show Help for Selection" which would bring up a static window with the help() contents.

A third possibility (best of both worlds?) would be a window that has a checkbox "Follow Selection", initially true. If you deselect it the window would stay open statically, and a subsequent "Show Help for Selection" command would bring up a new window with the checkbox checked.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711991&group_id=5470


From noreply@sourceforge.net  Sat Mar 29 23:38:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 15:38:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-708901 ] Lineno calculation sometimes broken
Message-ID: 

Bugs item #708901, was opened at 2003-03-24 12:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: Lineno calculation sometimes broken

Initial Comment:
I'm running the win32 version of Python 2.3a2.  I ran into 
this when I got a traceback pointing to a wrong 
linenumber.  It also messes up debugging in 
Pythonwin.  Anyway, you can see from the disassembly 
below that something goes seriously amiss when the 
code reaches the FOR_ITER:


>>> import httplib
>>> import dis
>>> dis.dis(httplib.HTTPConnection.connect)
524           0 LOAD_CONST

              3 STORE_FAST

525           6 SETUP_LOOP
              9 LOAD_GLOBAL
             12 LOAD_ATTR
             15 LOAD_FAST
             18 LOAD_ATTR
             21 LOAD_FAST
             24 LOAD_ATTR
             27 LOAD_CONST

526          30 LOAD_GLOBAL
             33 LOAD_ATTR
             36 CALL_FUNCTION
             39 GET_ITER

781     >>   40 FOR_ITER


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 18:38

Message:
Logged In: YES 
user_id=33168

The patch worked for me on Linux, after I removed
httplib.pyc. :-)
Does it jump to the right line in the debugger whe iterating
through a loop?

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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:43

Message:
Logged In: YES 
user_id=6656

Stupid minimal testcase:

def f():
    for res in range(1,
                     10):
        pass

Tim, you've looked at compile.c today , can you check
the attached patch?


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:36

Message:
Logged In: YES 
user_id=6656

Waddya know, it's not my fault.

For some reason, something is trying to store a negative
line_incr into the c_lnotab which gets masked into a line
increment of 255.  Fun.


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

Comment By: Michael Hudson (mwh)
Date: 2003-03-24 12:16

Message:
Logged In: YES 
user_id=6656

yow!  probably my fault.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=708901&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 02:17:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 18:17:05 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-694320 ] Add list.join()
Message-ID: 

Feature Requests item #694320, was opened at 2003-02-27 07:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694320&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Daniel (kamek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add list.join()

Initial Comment:
While there's string.join(list), I believe it'd make much 
more sense to have list.join(string). In most languages 
(and also in the string module), the first argument for join 
functions is the list, and the second is the separator. 
Not to mention code using methods directly in strings, 
like "' '.join(...)" is uglier :)

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

>Comment By: Tim Peters (tim_one)
Date: 2003-03-29 21:17

Message:
Logged In: YES 
user_id=31435

Guido has rejected this so often there's no point keeping 
this open, so I'm just closing it.  Martin actually undersold 
the difficulty of implementing this  string.join(x) works for 
any iterable x, and that's a much larger set of objects than 
just sequences.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 10:13

Message:
Logged In: YES 
user_id=21627

This has been discussed many times, and each time the
conclusion was that the idea is flawed, as it would require
adding join operations not only to lists, but to all
sequences. For example, Python currently supports

>>> "u".join("Hallo")
'Huaululuo'



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694320&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 03:44:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 19:44:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-29 21:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 05:10:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 29 Mar 2003 21:10:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-707074 ] timeouts incompatible w/ line-oriented protocols
Message-ID: 

Bugs item #707074, was opened at 2003-03-20 12:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: timeouts incompatible w/ line-oriented protocols

Initial Comment:
I've come to the conclusion that, as written, the higher level line-
oriented protocols which use the socket library (httplib, ftplib,
xmlrpclib, etc) won't work with socket timeouts.  They generally do
something like:

    self.file = self.sock.makefile('rb')

then use file methods to send and receive data on the socket.

Alas, the socket docs state:

Timeout mode internally sets the socket in non-blocking mode.
The blocking and timeout modes are shared between file descriptors
and socket objects that refer to the same network endpoint.  A
consequence of this is that file objects returned by the makefile()
method should only be used when the socket is in blocking mode; in
timeout or non-blocking mode file operations that cannot be
completed immediately will fail.  

I view this state of affairs as a bug which should be fixed at some
point, as these higher level protocol modules are probably the 
predominant way sockets get used in Python programs.


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-03-29 23:10

Message:
Logged In: YES 
user_id=44345

Okay, checked in and closed.  Let's see who screams.

Lib/socket.py 1.36
Lib/test/test_urllibnet.py 1.1
Misc/NEWS 1.705

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 16:55

Message:
Logged In: YES 
user_id=33168

This works for me on linux.  I don't know if there's any
issue wrt to removing _needwrapper.  Perhaps it should be
checked in and see if anyone complains?  I'm not sure who
else should review this patch.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-24 11:23

Message:
Logged In: YES 
user_id=44345

Jack, Any chance you can simply apply it to the source and see how it goes
on MacOS9? -Skip

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

Comment By: Jack Jansen (jackjansen)
Date: 2003-03-24 04:58

Message:
Logged In: YES 
user_id=45365

If this patch is accepted: may I request it be done soon? Changes like this often affect how things work on MacOS9 (IOW: break things on MacOS9:-), and in general changing the makefile() semantics on all non-windows platforms is something that may turn up hidden bugs, so I don't think we want this in as a last-second mod before 2.3b1 goes out.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-21 12:02

Message:
Logged In: YES 
user_id=44345

The attached simple patch to socket.py seems to do the trick.  No tests
fail as a result.  The new test_urllibnet test case fails on Mac OS X
without the patch and succeeds with the patch.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707074&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 09:00:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 01:00:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-704641 ] _tkinter.c won't build w/o threads?
Message-ID: 

Bugs item #704641, was opened at 2003-03-16 21:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470

Category: Tkinter
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Speno (corvus)
Assigned to: Nobody/Anonymous (nobody)
Summary: _tkinter.c won't build w/o threads?

Initial Comment:
I'm out of my area of expertice here trying to build python on Windows using cygwin and trying to use Tcl/Tk 8.4.2, but...

Anyway, it looks like I can't compile _tkinter.c unless I've configured python to use threads and I didn't because the main python README says not to with cygwin.

For example, tcl_lock is used in many places in _tkinter.c but it is only defined when WITH_THREAD is defined.

And there's no Sleep() function when WITH_THREADS is off, and that's used in WaitForMainLoop().

And in Tkapp_New() there's a call to PyThread_free_lock() that isn't inside an #ifdef WITH_THREAD block.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 11:00

Message:
Logged In: YES 
user_id=21627

This is now fixed in _tkinter.c 1.153.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-28 18:52

Message:
Logged In: YES 
user_id=86216

Given that this is most likely a generic Unix issue, I prefer
that someone better qualified to resolve this problem be
assigned.

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

Comment By: John Speno (corvus)
Date: 2003-03-27 03:06

Message:
Logged In: YES 
user_id=2138

It fails on MacOS X when made w/o threads. That's unix enough.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-26 23:59

Message:
Logged In: YES 
user_id=21627

This is my suspicion. I haven't tried building Python on a
Unix system without threads, but I suspect it fails as well.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-26 22:30

Message:
Logged In: YES 
user_id=86216

loewis> Building _tkinter without threads should be supported.

Does the above imply that this is a generic Unix as oppose to
Cygwin specific problem?


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 19:16

Message:
Logged In: YES 
user_id=21627

Building _tkinter without threads should be supported.

Would anybody want to write a patch to add the missing
WITH_THREAD tests?

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

Comment By: John Speno (corvus)
Date: 2003-03-19 04:29

Message:
Logged In: YES 
user_id=2138

jlt63> Do you really need to build CVS? Or, will the pre-built
jlt63> Cygwin Python 2.2.2 suffice?

At the time, I needed 2.3a2. However, I was able to use a pre-built version for Windows and replace the included Tcl/Tk with 8.4.2. So, I'm good for now.

Is it really the case that you need to build Python with threads in order to build Tkinter? Why bother with all those #ifdef WITH_THREAD in _tkinter.c if building w/o threads isn't an option? Once I added them in, everything compiled and using Tkinter didn't give me any errors. It didn't give me any widgets on screen either, but I don't think that was related. :-)

Take care.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-03-19 04:09

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, can you help with this?

Yes. The short answer is I have been meaning to
update the official Python README. I guess that
I can't procrastinate anymore...

corvus> I'm out of my area of expertice here trying
corvus> to build python on Windows using cygwin
corvus> and trying to use Tcl/Tk 8.4.2, but... 

Do you really need to build CVS? Or, will the pre-built
Cygwin Python 2.2.2 suffice?

corvus> Anyway, it looks like I can't compile _tkinter.c
corvus> unless I've configured python to use threads
corvus> and I didn't because the main python README
corvus> says not to with cygwin.

Well, that's simple the "main python README" is wrong.
See above. :,)

If _tkinter requires threads under other Unixes, then I
think that updating the official Python README is
sufficient. Do others agree?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-19 01:44

Message:
Logged In: YES 
user_id=33168

Jason, can you help with this?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704641&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 09:05:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 01:05:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-30 05:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 11:05

Message:
Logged In: YES 
user_id=21627

It is surprising that it runs into iconv, as test_pep263
should use encodings.koi8_r.Codec, not the IconvCodec. What
do you get if you do

codecs.lookup("koi8-r")

In any case, the iconv codec (when used) should not crash.
It looks like there is some memory corruption going on.
However, without an OpenBSD system to debug libiconv, this
probably won't be found.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 11:10:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 03:10:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-702858 ] deepcopy can't copy self-referential new-style classes
Message-ID: 

Bugs item #702858, was opened at 2003-03-13 03:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702858&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen C Phillips (scp93ch)
Assigned to: Nobody/Anonymous (nobody)
Summary: deepcopy can't copy self-referential new-style classes

Initial Comment:
Given this code:

import copy
class Foo(object):
    pass
f = Foo()
f.bar = f
g = copy.deepcopy(f)

You will find with Python 2.3a2 and 2.2.2:

f is f.bar   ->  True
g is g.bar   ->  False
g is not f   -> True
g.bar is not f   -> True

Obviously, all the statements should be True.



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

Comment By: Steven Taschuk (staschuk)
Date: 2003-03-30 04:10

Message:
Logged In: YES 
user_id=666873

See patch 707900.

http://www.python.org/sf/707900

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702858&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 14:53:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 06:53:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-704996 ] HTMLParser fails on 
Message-ID: 

Bugs item #704996, was opened at 2003-03-17 15:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704996&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: gary aviv (aaii1025)
Assigned to: Martin v. Löwis (loewis)
Summary: HTMLParser fails on 

Initial Comment:
HTMLParser can't handle constructs such as:


...


which is found in MS Word documents saved as HTML.

The problem is in markupbase.py  

Suggest the follwoing patch:

diff -u /usr/local/lib/python2.2/markupbase.py.orig
/usr/local/lib/python2.2/markupbase.py
--- /usr/local/lib/python2.2/markupbase.py.orig Mon Mar
17 09:23:17 2003
+++ /usr/local/lib/python2.2/markupbase.py      Mon Mar
17 09:26:45 2003
@@ -3,7 +3,8 @@
 import re
 import string

-_declname_match =
re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*').match
+#_declname_match =
re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*').match  # was this
+_declname_match =
re.compile(r'[a-zA-Z][-_.a-zA-Z0-9]*\s*|\[.*\]').match
# replace by this
 _declstringlit_match =
re.compile(r'(\'[^\']*\'|"[^"]*")\s*').match

 del re
@@ -73,7 +74,7 @@
             if c == ">":
                 # end of declaration syntax
                 data = rawdata[i+2:j]
-                if decltype == "doctype":
+                if decltype == "doctype" or
decltype[0] == '[':        # handle 
                     self.handle_decl(data)
                 else:
                     self.unknown_decl(data)
@@ -310,7 +311,7 @@
             return string.lower(name), m.end()
         else:
             self.updatepos(declstartpos, i)
-            self.error("expected name token")
+            self.error("expected name token '%s'" %
rawdata[i:i+10]) # improve error message

     # To be overridden -- handlers for unknown objects
     def unknown_decl(self, data):

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 16:53

Message:
Logged In: YES 
user_id=21627

This has now been fixed with patch 545300.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=704996&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 14:52:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 06:52:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-505747 ] markupbase handling of HTML declarations
Message-ID: 

Bugs item #505747, was opened at 2002-01-19 15:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: markupbase handling of HTML declarations

Initial Comment:
Using Python 2.2., I tried to use websucker.py on this 
page:

http://magix.fri.uni-lj.si/orange/start/

This resulted in an exception in ParserBase._scan_name 
because _declname_match failed.  Examining the source 
for the page above, I see there are several tags that 
look like: "" where the first character 
after "Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 16:52

Message:
Logged In: YES 
user_id=21627

This has now been fixed with patch 545300, on grounds of
conformance with SGML.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-14 03:39

Message:
Logged In: YES 
user_id=3066

Ok, here's what I think.

This is not an actual bug in the interpretation of HTML, and
there has not been a recurring pattern of complaints about
this.  Given that we do not want to encourage the creation
of broken HTML, this edge case will not be allowed to
further complicate the code.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-15 07:13

Message:
Logged In: YES 
user_id=3066

Ugh!  I don't think that's legal HTML at all.  I'll have to
think about the right way to deal with it.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 15:53:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 07:53:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-701823 ] configure option --enable-shared make problems
Message-ID: 

Bugs item #701823, was opened at 2003-03-11 22:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701823&group_id=5470

Category: Installation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Uwe Hoffmann (qual)
Assigned to: Martin v. Löwis (loewis)
Summary: configure option --enable-shared make problems 

Initial Comment:
on  building python 2.3.a2 with the following lines

./configure --prefix=/tmp/python --enable-shared
--with-cxx=g++ --with-signal-module --with-threads ; 
make ;
make install;

the installed python interpreter cann't be started because 
libpython2.3.so.1.0 is installed but not libpython2.3.so .

the attached patch works in my environment.

Linux ; glibc 2.2.5; gcc 3.2; binutils 2.13

at least solaris should suffer from the same problem.


(the change for configure.in is not tested,  the changes
were directly made to configure)

the same can be achieved if libpython$(VERSION)$(SO) 
(actually libpython2.3.so ) is installed and not
$(INSTSONAME)  ( actually libpython2.3.so.1.0) .

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 17:53

Message:
Logged In: YES 
user_id=21627

This is fixed in Makefile.pre.in 1.119 (in a different way).

On Solaris, the same problem does not exists, since
SOVERSION is only used on Linux.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701823&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 15:57:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 07:57:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX
Message-ID: 

Bugs item #678259, was opened at 2003-01-31 19:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: locale.getpreferredencoding fails on AIX

Initial Comment:

The problem is setting LC_CTYPE to an empty string:

>>> locale.setlocale(locale.LC_CTYPE, '')
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/neal/python/dist/aix/Lib/locale.py", line 
381, in setlocale
    return _setlocale(category, locale)
locale.Error: locale setting not supported

Putting a try/except around the setlocale call in 
getpreferredencoding allows the test to pass.  I don't 
know if this is correct.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 17:57

Message:
Logged In: YES 
user_id=21627

I guess the empty string should be accepted (although this
is debatable: it won't honor the user preferences if the
user had some).

Fixed in locale.py 1.25.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-21 16:36

Message:
Logged In: YES 
user_id=33168

The traceback from the original report was not the same as
my last comment.  The original problem seems to be gone.  I
don't know what changed, but the localemodule builds and
tests correctly.  However, before getting the module to
build, I was using the python version.  The python version
of setlocale() doesn't support setting a value to an empty
string.  Based on your first comment, it seems the python
version (line 72 of locale.py) should allow the value to be
either '' or 'C'.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-21 08:10

Message:
Logged In: YES 
user_id=21627

I don't understand. In the traceback, it says that
_setlocale is invoked, which is the function from
_localemodule. Since the locale argument is still an empty
string, it still seems to be a flaw in the AIX
implementation, or else the user has environment settings
which are not supported by AIX.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-21 04:28

Message:
Logged In: YES 
user_id=33168

The problem was that the setlocale in Lib/locale.py was
being used, not from Modules/_localemodule.c.  In the python
version, it does not allow an empty string.  Seems like this
should be changed, do you agree?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-04 00:11

Message:
Logged In: YES 
user_id=21627

What are the relevant environment settings? According to

http://nscp.upenn.edu/aix4.3html/libs/basetrf2/setlocale.htm

specifying "" as the second argument of setlocale is
supported, and means the same thing as it does on all other
systems: take locale settings from the user preferences.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 16:15:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 08:15:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-678264 ] test_resource fails when file size is limited
Message-ID: 

Bugs item #678264, was opened at 2003-01-31 19:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: test_resource fails when file size is limited

Initial Comment:
test_resource does:

   print resource.RLIM_INFINITY == max

I'm not sure of the benefit of this line.  For machines 
which have limited file sizes, it causes the test to fail.  
Otherwise the test seems to work properly.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 18:15

Message:
Logged In: YES 
user_id=21627

The rationale of the line is explained in the comment: The
code tests whether the limit is a really large number, i.e.
whether represenation of large limits works.

Unfortunately, it doesn't  (which is a separate issue): On
Linux, RLIM_INFINITY is reported as -1. This comes from
RLIM_INFINITY being the larges unsigned long long number,
i.e. 0xffffffffffffffffuLL. The resource module represents
this incorrectly.

I think there is no way to verify that Python computes the
real limit correctly (unless we invoke the shell's ulimit
for comparison). So you could weaken the test to verify that
the limit is non-negative (and, as a side effect, verify
that it doesn't raise an exception).

If you do so, you'll also have to fix the implementation, so
that the weakened-strengthened test passes on Linux.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 23:17

Message:
Logged In: YES 
user_id=33168

Martin, welcome back!  Now I get to assign some bugs to you
to see if you have any input. :-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 16:18:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 08:18:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris
Message-ID: 

Bugs item #700780, was opened at 2003-03-10 12:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Iain Morrison (iainmorrison)
Assigned to: Nobody/Anonymous (nobody)
Summary: ncurses/curses on solaris

Initial Comment:
solaris 8 [sparc]
gcc 3.2.2
python 2.2.2

I am having trouble with curses support.  ncurses 5.3
is installed in the standard solaris manner

** Configuration summary for NCURSES 5.3 20021012:

      bin directory: /usr/local/bin
      lib directory: /usr/local/lib
  include directory: /usr/local/include/ncurses
      man directory: /usr/local/man
 terminfo directory: /usr/local/share/terminfo

** Include-directory is not in a standard location

is not picked up by ./configure.
 
checking for ncurses.h... no

Python builds fine but

./python ./Lib/test/test_curses.py -u curses
Traceback (most recent call last):
  File "./Lib/test/test_curses.py", line 11, in ?
    import curses, sys, tempfile
  File
"/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py",
line 15, in ?
    from _curses import *
ImportError: No module named _curses

I'm doing something wrong but I'm nor sure what.  Do I
need to have ncurses overwrite the default Solaris
curses? If so will anything break?


many thanks

iain morrison

iain.morrison@mrc-cbu.cam.ac.uk



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 18:18

Message:
Logged In: YES 
user_id=21627

What is the ncurses portion of running setup.py?

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

Comment By: Iain Morrison (iainmorrison)
Date: 2003-03-25 17:11

Message:
Logged In: YES 
user_id=720523

Using

setenv CPPFLAGS -I/usr/local/include/ncurses

and running

./configure


I get

checking for ncurses.h... yes


However the Makefile is identival to that produced without CPPFLAGS 
set. The curses test still fails

178 tests OK.
15 tests skipped:
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_email_codecs test_gdbm test_gl test_imgfile
    test_linuxaudiodev test_locale test_openpty test_winreg
    test_winsound

./python ./Lib/test/test_curses.py -u curses
Traceback (most recent call last):
  File "./Lib/test/test_curses.py", line 11, in ?
    import curses, sys, tempfile
  File "/usr/local/src/python/Python-2.2.2-test/Lib/curses/__init__.py", 
line 15, in ?
    from _curses import *
ImportError: No module named _curses



diff configure-output ../Python-2.2.2/configure-output
39c39
< checking for ncurses.h... yes
---
> checking for ncurses.h... no

diff Makefile ../Python-2.2.2/Makefile


Anything else I can try

iain

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-15 14:44

Message:
Logged In: YES 
user_id=21627

Did you expect to use ncurses, or did you mean to use curses?

What is the ncurses portion of running setup.py?

To eliminate setup.py problems, you can always edit
Modules/Setup.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-03-14 16:45

Message:
Logged In: YES 
user_id=11375

Your compiler may not be looking in /usr/local/ for headers and libraries.  You shouldn't install ncurses over Solaris curses; locally-installed software belongs in /usr/local/, period.

When you run the configure script, you can supply environment variables to add compiler flags; run configure --help to see a list.

I'd suggest something like 'CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure', and see if it picks up ncurses.h then.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 18:42:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 10:42:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-683061 ] gzip module cannot write large files
Message-ID: 

Bugs item #683061, was opened at 2003-02-08 12:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683061&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip module cannot write large files

Initial Comment:
Something like this:

import gzip
fin = open("/dev/urandom", "rb")
fout = gzip.GzipFile("out", "wb")
for i in range(4500): fout.write(fin.read(1024*1024))
fout.close()

will result in an error like:

Exception 'long int too large to convert to int' raised
of class 'exceptions.OverflowError':
...
  File "/usr/local/lib/python2.2/gzip.py", line 253, in
close
    write32(self.fileobj, self.size)
  File "/usr/local/lib/python2.2/gzip.py", line 19, in
write32
    output.write(struct.pack("

Feature Requests item #507262, was opened at 2002-01-22 18:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=507262&group_id=5470

Category: None
Group: None
Status: Closed
>Resolution: Rejected
Priority: 2
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: GNU --option syntax not supported

Initial Comment:
It would be good if the python interpreter 
supported standard GNU --log style options as
well.

Jari

//root@W2KPICASSO /usr/bin $ python -V
Python 2.2
//root@W2KPICASSO /usr/bin $ python --help
Unknown option: --
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Try `python -h' for more information.
//root@W2KPICASSO /usr/bin $ python -h    
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Options and arguments (and corresponding environment 
variables):
-c cmd : program passed in as string (terminates 
option list)
-d     : debug output from parser (also PYTHONDEBUG=x)
-E     : ignore environment variables (such as 
PYTHONPATH)
-h     : print this help message and exit
-i     : inspect interactively after running script, 
(also PYTHONINSPECT=x)
         and force prompts, even if stdin does not 
appear to be a terminal
-O     : optimize generated bytecode (a tad; also 
PYTHONOPTIMIZE=x)
-OO    : remove doc-strings in addition to the -O 
optimizations
-Q arg : division options: -Qold (default), -Qwarn, -
Qwarnall, -Qnew
-S     : don't imply 'import site' on initialization
-t     : issue warnings about inconsistent tab usage (-
tt: issue errors)
-u     : unbuffered binary stdout and stderr (also 
PYTHONUNBUFFERED=x)
-U     : Unicode literals: treats '...' literals like 
u'...'
-v     : verbose (trace import statements) (also 
PYTHONVERBOSE=x)
-V     : print the Python version number and exit
-W arg : warning control (arg is 
action:message:category:module:lineno)
-x     : skip first line of source, allowing use of 
non-Unix forms of #!cmd
file   : program read from script file
-      : program read from stdin (default; interactive 
mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup 
(no default)
PYTHONPATH   : ':'-separated list of directories 
prefixed to the
               default module search path.  The result 
is sys.path.
PYTHONHOME   : alternate  directory (or 
:).
               The default module search path uses 
/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements 
(Windows).


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-30 14:00

Message:
Logged In: YES 
user_id=6380

Martin: he doesn't mean the getopt module, he wants the
python interpreter's own options to support long options. I
personally don't care and think this is a waste of time, so
I'll reject it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 10:03

Message:
Logged In: YES 
user_id=21627

In Python 2.3, getopt supports gnu_getopt, so this feature
is now implemented.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:00

Message:
Logged In: YES 
user_id=21627

Moved to the feature requests tracker.

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

Comment By: Jari Aalto (jaalto)
Date: 2002-03-10 03:02

Message:
Logged In: YES 
user_id=65014


Sorry for the typo: I meant "GNU 'long' style options",
it would be good if there were legible options like

-h  => --help

Although Python is not GNU program, the "--long" style
option usage is "de facto" accepted in almost everywhere.

I would see it a good addition to Python.




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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-09 09:03

Message:
Logged In: YES 
user_id=6380

Rather than quoting the Python -h output (with which I am
quite familiar, thank you!), you could explain what --log is
supposed to do. What does it do and why do you want it? (BTW
Python is not GNU software.)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=507262&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 19:54:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 11:54:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch
Message-ID: 

Bugs item #697220, was opened at 2003-03-04 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Gerhard Häring (ghaering)
Summary: string.strip implementation/doc mismatch

Initial Comment:
#v+
>>> "test".strip("t")
'es'
>>> import string
>>> print string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>
#v-

*But* the Python documentation says that not only the
string *method* strip() will allow a second optional
argument, but also the strip function in the string
module.
(http://www.python.org/doc/current/lib/module-string.html)

string.strip should be changed to accept the additional
 parameter.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 14:54

Message:
Logged In: YES 
user_id=33168

Updated both patches to fix problem with sep--changed
docstrings to use chars.  Updated string_tests for 2.3.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-20 06:36

Message:
Logged In: YES 
user_id=89016

In the patch for 2.3 a few docstrings in string.py still
mention sep instead of chars. The tests in
test/string_tests.py::MixinStrUnicodeUserStringTest.test_strip_args()
should be moved to CommonTest.test_strip() so that these
tests will be run for the string module too.

I haven't looked at the 2.2.3 patch yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-06 01:25

Message:
Logged In: YES 
user_id=33168

Gerhard, hopefully I've cleaned things up this time.  Could
you review both patches attached (one for 2.2.3, the other
for 2.3)?  I will send a message to python-dev to get
concurrence on the changes and hopefully more review.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 13:20

Message:
Logged In: YES 
user_id=33168

Thanks, you are correct.  The problem was with the string
object, not the string module.  :-(  I need to look at this
more.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-04 13:10

Message:
Logged In: YES 
user_id=163326

Neil, I don't think this was implemented in the 2.2
maintenance branch. That's why I'm reopening this. At least
for my 2.2 Pythons string.strip accepts one parameter only:

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 string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>

and

Python 2.2.2 (#1, Feb  9 2003, 13:22:07)
[GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)

Confused.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 12:55

Message:
Logged In: YES 
user_id=33168

Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before
do not.  We should really update the doc.  I thought this
was done, but apparently not.

Checked in as: libstring.tex 1.45.8.4

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 19:55:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 11:55:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-697220 ] string.strip implementation/doc mismatch
Message-ID: 

Bugs item #697220, was opened at 2003-03-04 07:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Gerhard Häring (ghaering)
>Assigned to: Walter Dörwald (doerwalter)
Summary: string.strip implementation/doc mismatch

Initial Comment:
#v+
>>> "test".strip("t")
'es'
>>> import string
>>> print string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>
#v-

*But* the Python documentation says that not only the
string *method* strip() will allow a second optional
argument, but also the strip function in the string
module.
(http://www.python.org/doc/current/lib/module-string.html)

string.strip should be changed to accept the additional
 parameter.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 14:54

Message:
Logged In: YES 
user_id=33168

Updated both patches to fix problem with sep--changed
docstrings to use chars.  Updated string_tests for 2.3.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-03-20 06:36

Message:
Logged In: YES 
user_id=89016

In the patch for 2.3 a few docstrings in string.py still
mention sep instead of chars. The tests in
test/string_tests.py::MixinStrUnicodeUserStringTest.test_strip_args()
should be moved to CommonTest.test_strip() so that these
tests will be run for the string module too.

I haven't looked at the 2.2.3 patch yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-06 01:25

Message:
Logged In: YES 
user_id=33168

Gerhard, hopefully I've cleaned things up this time.  Could
you review both patches attached (one for 2.2.3, the other
for 2.3)?  I will send a message to python-dev to get
concurrence on the changes and hopefully more review.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 13:20

Message:
Logged In: YES 
user_id=33168

Thanks, you are correct.  The problem was with the string
object, not the string module.  :-(  I need to look at this
more.

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

Comment By: Gerhard Häring (ghaering)
Date: 2003-03-04 13:10

Message:
Logged In: YES 
user_id=163326

Neil, I don't think this was implemented in the 2.2
maintenance branch. That's why I'm reopening this. At least
for my 2.2 Pythons string.strip accepts one parameter only:

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 string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)
>>>

and

Python 2.2.2 (#1, Feb  9 2003, 13:22:07)
[GCC 3.2.1 [FreeBSD] 20021119 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> import string
>>> string.strip("test", "t")
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: strip() takes exactly 1 argument (2 given)

Confused.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-04 12:55

Message:
Logged In: YES 
user_id=33168

Gerhard, 2.2.2 does have 2 arguments, but 2.2.1 and before
do not.  We should really update the doc.  I thought this
was done, but apparently not.

Checked in as: libstring.tex 1.45.8.4

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697220&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 20:19:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 12:19:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-548176 ] urlparse doesn't handle host?bla
Message-ID: 

Bugs item #548176, was opened at 2002-04-24 09:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Demleitner (msdemlei)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse doesn't handle host?bla

Initial Comment:
The urlparse module (at least in 2.2 and 2.1, Linux)
doesn't
handle URLs of the form
http://www.maerkischeallgemeine.de?loc_id=49 correctly
-- everything up to the 9 ends up in the host.  I
didn't check the RFC, but in the real world URLs like
this do show up.  urlparse works fine when there's a
trailing slash on the host name:
http://www.maerkischeallgemeine.de/?loc_id=49

Example:

>>> import urlparse
>>>
urlparse.urlparse("http://www.maerkischeallgemeine.de/?loc_id=49")
('http', 'www.maerkischeallgemeine.de', '/', '',
'loc_id=49', '')
>>>
urlparse.urlparse("http://www.maerkischeallgemeine.de?loc_id=49")
('http', 'www.maerkischeallgemeine.de?loc_id=49', '',
'', '', '')



This has serious implications for urllib, since
urllib.urlopen will fail for URLs like the second one,
and with a pretty mysterious exception ("host not
found") at that.

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

Comment By: Steven Taschuk (staschuk)
Date: 2003-03-30 13:19

Message:
Logged In: YES 
user_id=666873

For comparison, RFC 1738 section 3.3:
   An HTTP URL takes the form:
      http://:/?
   [...] If neither  nor  is present,
   the "/" may also be omitted.
... which does not outright say the '/' may *not* be omitted if 
 is absent but  is present (though imho 
that's implied).

But even if the / may not be omitted in this case, ? is not 
allowed in the authority component under either RFC 2396 or 
RFC 1738, so urlparse should either treat it as a delimiter or 
reject the URL as malformed.  The principle of being lenient in 
what you accept favours the former.

I've just submitted a patch (712317) for this.

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

Comment By: Jeff Epler (jepler)
Date: 2002-11-17 09:56

Message:
Logged In: YES 
user_id=2772

This actually appears to be permitted by RFC2396
[http://www.ietf.org/rfc/rfc2396.txt].   See section 3.2:


3.2. Authority Component

   Many URI schemes include a top hierarchical element for a
naming authority, such that the namespace defined by the
remainder of the URI is governed by that authority.  This
authority component is typically defined by an
Internet-based server or a scheme-specific registry of
naming authorities.

      authority     = server | reg_name

   The authority component is preceded by a double slash
"//" and is terminated by the next slash "/", question-mark
"?", or by the end of the URI.  Within the authority
component, the characters ";", ":", "@", "?", and "/" are
reserved.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 20:25:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 12:25:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-678264 ] test_resource fails when file size is limited
Message-ID: 

Bugs item #678264, was opened at 2003-01-31 13:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Martin v. Löwis (loewis)
Summary: test_resource fails when file size is limited

Initial Comment:
test_resource does:

   print resource.RLIM_INFINITY == max

I'm not sure of the benefit of this line.  For machines 
which have limited file sizes, it causes the test to fail.  
Otherwise the test seems to work properly.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 15:25

Message:
Logged In: YES 
user_id=33168

Hmmm, sounds like a lot of work.  How about something like this:

    expected_max = resource.RLIM_INFINITY
    if expected_max != max:
        # read the file resource limit
        fsize_ulimit = os.popen('ulimit -f').read()
        try:
            # convert the file size to bytes (from 512 byte
blocks)
            expected_max = int(fsize_ulimit.strip()) * 512
        except ValueError:
            raise TestSkipped, "unable to determine expected
resource value"
    print expected_max == max

This works, but I'm pretty sure this is not portable.  On
Linux blocks are 1k.  This only works when the block size is
512 bytes.  Shall we close this bug as a test environment
problem and won't fix?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 11:15

Message:
Logged In: YES 
user_id=21627

The rationale of the line is explained in the comment: The
code tests whether the limit is a really large number, i.e.
whether represenation of large limits works.

Unfortunately, it doesn't  (which is a separate issue): On
Linux, RLIM_INFINITY is reported as -1. This comes from
RLIM_INFINITY being the larges unsigned long long number,
i.e. 0xffffffffffffffffuLL. The resource module represents
this incorrectly.

I think there is no way to verify that Python computes the
real limit correctly (unless we invoke the shell's ulimit
for comparison). So you could weaken the test to verify that
the limit is non-negative (and, as a side effect, verify
that it doesn't raise an exception).

If you do so, you'll also have to fix the implementation, so
that the weakened-strengthened test passes on Linux.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 17:17

Message:
Logged In: YES 
user_id=33168

Martin, welcome back!  Now I get to assign some bugs to you
to see if you have any input. :-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 20:32:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 12:32:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 15:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Just van Rossum (jvr)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 20:34:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 12:34:34 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired
Message-ID: 

Feature Requests item #706392, was opened at 2003-03-19 11:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-30 14:34

Message:
Logged In: YES 
user_id=470295

Aha, now I see what you are suggesting.  I didn't quite understand what you intended before.  This (wrapping sockaddr and having connect check for the wrapped object) sounds like a very plausible idea.  I will consider strongly doing it this way.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 11:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 09:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 20:49:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 12:49:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-678264 ] test_resource fails when file size is limited
Message-ID: 

Bugs item #678264, was opened at 2003-01-31 19:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Martin v. Löwis (loewis)
Summary: test_resource fails when file size is limited

Initial Comment:
test_resource does:

   print resource.RLIM_INFINITY == max

I'm not sure of the benefit of this line.  For machines 
which have limited file sizes, it causes the test to fail.  
Otherwise the test seems to work properly.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 22:49

Message:
Logged In: YES 
user_id=21627

I'm really not that much concerned about fixing the test,
but more about fixing the code itself.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 22:25

Message:
Logged In: YES 
user_id=33168

Hmmm, sounds like a lot of work.  How about something like this:

    expected_max = resource.RLIM_INFINITY
    if expected_max != max:
        # read the file resource limit
        fsize_ulimit = os.popen('ulimit -f').read()
        try:
            # convert the file size to bytes (from 512 byte
blocks)
            expected_max = int(fsize_ulimit.strip()) * 512
        except ValueError:
            raise TestSkipped, "unable to determine expected
resource value"
    print expected_max == max

This works, but I'm pretty sure this is not portable.  On
Linux blocks are 1k.  This only works when the block size is
512 bytes.  Shall we close this bug as a test environment
problem and won't fix?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 18:15

Message:
Logged In: YES 
user_id=21627

The rationale of the line is explained in the comment: The
code tests whether the limit is a really large number, i.e.
whether represenation of large limits works.

Unfortunately, it doesn't  (which is a separate issue): On
Linux, RLIM_INFINITY is reported as -1. This comes from
RLIM_INFINITY being the larges unsigned long long number,
i.e. 0xffffffffffffffffuLL. The resource module represents
this incorrectly.

I think there is no way to verify that Python computes the
real limit correctly (unless we invoke the shell's ulimit
for comparison). So you could weaken the test to verify that
the limit is non-negative (and, as a side effect, verify
that it doesn't raise an exception).

If you do so, you'll also have to fix the implementation, so
that the weakened-strengthened test passes on Linux.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 23:17

Message:
Logged In: YES 
user_id=33168

Martin, welcome back!  Now I get to assign some bugs to you
to see if you have any input. :-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 21:03:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 13:03:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 22:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Just van Rossum (jvr)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 21:05:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 13:05:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-29 21:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

>Comment By: logistix (logistix)
Date: 2003-03-30 15:05

Message:
Logged In: YES 
user_id=699438

Okay, I lied.  I'm primarily a windows developer who's a bit  
new to the wonderful world of gdb!  It found the codec fine.   
libiconv was just the last library that gdb imported a symbol 
table from. 
  
The error actaully occurs on a realloc() to a list object.  I've  
attached the stack trace if it means anything.  
  
 man realloc also explains the error message: 
 
``modified (chunk-/page-) pointer.'' 
	The pointer passed to free or realloc has been modified. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 03:05

Message:
Logged In: YES 
user_id=21627

It is surprising that it runs into iconv, as test_pep263
should use encodings.koi8_r.Codec, not the IconvCodec. What
do you get if you do

codecs.lookup("koi8-r")

In any case, the iconv codec (when used) should not crash.
It looks like there is some memory corruption going on.
However, without an OpenBSD system to debug libiconv, this
probably won't be found.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 21:27:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 13:27:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-30 05:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 23:27

Message:
Logged In: YES 
user_id=21627

The traceback is bogus. For example, in stackframe 19,
decode_str does not feature a call to PyUnicodeUCS2_Decode.
The most likely reason is that not all object files were
built with -g, so that some symbols are missing. I recommend
that you rebuild from scratch with --with-pydebug. Make sure
you have no object files left over from an earlier build.

If this causes the bug to disappear, configure with regular
options, and add -g to Makefile.pre manually. In either
case, verify that -g does get added to the compile commands.

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

Comment By: logistix (logistix)
Date: 2003-03-30 23:05

Message:
Logged In: YES 
user_id=699438

Okay, I lied.  I'm primarily a windows developer who's a bit  
new to the wonderful world of gdb!  It found the codec fine.   
libiconv was just the last library that gdb imported a symbol 
table from. 
  
The error actaully occurs on a realloc() to a list object.  I've  
attached the stack trace if it means anything.  
  
 man realloc also explains the error message: 
 
``modified (chunk-/page-) pointer.'' 
	The pointer passed to free or realloc has been modified. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 11:05

Message:
Logged In: YES 
user_id=21627

It is surprising that it runs into iconv, as test_pep263
should use encodings.koi8_r.Codec, not the IconvCodec. What
do you get if you do

codecs.lookup("koi8-r")

In any case, the iconv codec (when used) should not crash.
It looks like there is some memory corruption going on.
However, without an OpenBSD system to debug libiconv, this
probably won't be found.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 22:32:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 14:32:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 15:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Just van Rossum (jvr)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 23:00:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 15:00:59 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-712375 ] unicodedata should have a version available
Message-ID: 

Feature Requests item #712375, was opened at 2003-03-30 23:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=712375&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Matthew Farrow (jmfarrow)
Assigned to: Nobody/Anonymous (nobody)
Summary: unicodedata should have a version available

Initial Comment:
The unicodedata module should have a version (or
revision) symbol available as an entry containing the
corresponding Unicode revision from the Unicode data
encoded.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=712375&group_id=5470


From noreply@sourceforge.net  Sun Mar 30 23:59:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 15:59:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-707576 ] -i -u options give SyntaxError on Windows
Message-ID: 

Bugs item #707576, was opened at 2003-03-21 15:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470

Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Chris Withers (fresh)
Assigned to: Tim Peters (tim_one)
Summary: -i -u options give SyntaxError on Windows

Initial Comment:
C:\>python -i -u
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.
>>> print 1
  File "", line 1
    print 1
           ^
SyntaxError: invalid syntax
>>>

...and this behaviour continues, no mater what
statement you enter.

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

>Comment By: Chris Withers (fresh)
Date: 2003-03-30 23:59

Message:
Logged In: YES 
user_id=24723

OK :-)

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-27 03:58

Message:
Logged In: YES 
user_id=31435

The only way on Windows is to open a file yourself in text 
mode with buffer size 0, and either write to it directly, or 
set sys.stdout to it.

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

Comment By: Chris Withers (fresh)
Date: 2003-03-26 17:05

Message:
Logged In: YES 
user_id=24723

-u     : unbuffered binary stdout and stderr (also
PYTHONUNBUFFERED=x)

Hmmm... never noticed the binary bit before. 
Is there any way to get unbuffered output without it being
binary?

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

Comment By: Tim Peters (tim_one)
Date: 2003-03-21 16:30

Message:
Logged In: YES 
user_id=31435

Why do you call this a bug?  -u forces stdin into binary mode, 
and the Python grammar does not allow \r\n line endings in 
program text (it never has, BTW).  Program text has to come 
from a file opened in text mode on Windows, and what you're 
seeing here is the same as what you'd see if you did

f = open('some_python_program.py', 'rb')
exec f.read()

on Windows.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707576&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 04:10:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 20:10:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-29 21:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

>Comment By: logistix (logistix)
Date: 2003-03-30 22:10

Message:
Logged In: YES 
user_id=699438

Here's a (hopefully) non-bogus traceback. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 15:27

Message:
Logged In: YES 
user_id=21627

The traceback is bogus. For example, in stackframe 19,
decode_str does not feature a call to PyUnicodeUCS2_Decode.
The most likely reason is that not all object files were
built with -g, so that some symbols are missing. I recommend
that you rebuild from scratch with --with-pydebug. Make sure
you have no object files left over from an earlier build.

If this causes the bug to disappear, configure with regular
options, and add -g to Makefile.pre manually. In either
case, verify that -g does get added to the compile commands.

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

Comment By: logistix (logistix)
Date: 2003-03-30 15:05

Message:
Logged In: YES 
user_id=699438

Okay, I lied.  I'm primarily a windows developer who's a bit  
new to the wonderful world of gdb!  It found the codec fine.   
libiconv was just the last library that gdb imported a symbol 
table from. 
  
The error actaully occurs on a realloc() to a list object.  I've  
attached the stack trace if it means anything.  
  
 man realloc also explains the error message: 
 
``modified (chunk-/page-) pointer.'' 
	The pointer passed to free or realloc has been modified. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 03:05

Message:
Logged In: YES 
user_id=21627

It is surprising that it runs into iconv, as test_pep263
should use encodings.koi8_r.Codec, not the IconvCodec. What
do you get if you do

codecs.lookup("koi8-r")

In any case, the iconv codec (when used) should not crash.
It looks like there is some memory corruption going on.
However, without an OpenBSD system to debug libiconv, this
probably won't be found.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 05:43:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 21:43:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-30 05:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-03-31 07:43

Message:
Logged In: YES 
user_id=21627

That sounds reasonable, and suggests that the bug is within
libiconv. It crashes at the line

iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1");

Please do the following steps:

a) produce a preprocessor output of _iconv_module.c (with
--save-temps), to see what UNICODE_ENCODING expands to.

b) write a test program, with

#include 
int main()
{
  iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1");
}

and see whether this runs correctly. If it doesn't, it's an
OpenBSD bug, if it does, we would need debug information for
libiconv as well.

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

Comment By: logistix (logistix)
Date: 2003-03-31 06:10

Message:
Logged In: YES 
user_id=699438

Here's a (hopefully) non-bogus traceback. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 23:27

Message:
Logged In: YES 
user_id=21627

The traceback is bogus. For example, in stackframe 19,
decode_str does not feature a call to PyUnicodeUCS2_Decode.
The most likely reason is that not all object files were
built with -g, so that some symbols are missing. I recommend
that you rebuild from scratch with --with-pydebug. Make sure
you have no object files left over from an earlier build.

If this causes the bug to disappear, configure with regular
options, and add -g to Makefile.pre manually. In either
case, verify that -g does get added to the compile commands.

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

Comment By: logistix (logistix)
Date: 2003-03-30 23:05

Message:
Logged In: YES 
user_id=699438

Okay, I lied.  I'm primarily a windows developer who's a bit  
new to the wonderful world of gdb!  It found the codec fine.   
libiconv was just the last library that gdb imported a symbol 
table from. 
  
The error actaully occurs on a realloc() to a list object.  I've  
attached the stack trace if it means anything.  
  
 man realloc also explains the error message: 
 
``modified (chunk-/page-) pointer.'' 
	The pointer passed to free or realloc has been modified. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 11:05

Message:
Logged In: YES 
user_id=21627

It is surprising that it runs into iconv, as test_pep263
should use encodings.koi8_r.Codec, not the IconvCodec. What
do you get if you do

codecs.lookup("koi8-r")

In any case, the iconv codec (when used) should not crash.
It looks like there is some memory corruption going on.
However, without an OpenBSD system to debug libiconv, this
probably won't be found.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 07:11:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 23:11:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-712056 ] OpenBSD 3.2: make altinstall dumps core
Message-ID: 

Bugs item #712056, was opened at 2003-03-29 21:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenBSD 3.2: make altinstall dumps core

Initial Comment:
"make altinstall" fails when building on OpenBSD 3.2.   
The core dump appears to happen when the newly built 
python program attempts to byte-compile 
"./Lib/test/test_pep263.py".  A gdb 'bt' shows a 
segmentation fault in a call to libiconv.so.3.0's div() 
function. 
 
This could be a bug in libiconv.so's unicode handling. 
 
Also, running "./python ./Lib/test/test_pep263.py" from 
the newly built python throws an assertation error. 
 
I am using a home-built version of OpenBSD, so I'd 
appreciate it if someone else could verify this. 
 
make altinstall's output: 
 
... 
Compiling /usr/local/lib/python2.3/test/test_pep263.py ... 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
python in free(): warning: modified (chunk-) pointer. 
Memory fault (core dumped) 
*** Error code 139 
 

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

>Comment By: logistix (logistix)
Date: 2003-03-31 01:11

Message:
Logged In: YES 
user_id=699438

It's using 'ucs-2-internal' for it's UNICODE_ENCODING. 
 
The test progam you gave me ran just fine (no core dump). 
 
I'm trying to get some directions now on the recommended 
way to do a full system debug build.  When I do, I'll provide 
more info. 
 
 
 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 23:43

Message:
Logged In: YES 
user_id=21627

That sounds reasonable, and suggests that the bug is within
libiconv. It crashes at the line

iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1");

Please do the following steps:

a) produce a preprocessor output of _iconv_module.c (with
--save-temps), to see what UNICODE_ENCODING expands to.

b) write a test program, with

#include 
int main()
{
  iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1");
}

and see whether this runs correctly. If it doesn't, it's an
OpenBSD bug, if it does, we would need debug information for
libiconv as well.

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

Comment By: logistix (logistix)
Date: 2003-03-30 22:10

Message:
Logged In: YES 
user_id=699438

Here's a (hopefully) non-bogus traceback. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 15:27

Message:
Logged In: YES 
user_id=21627

The traceback is bogus. For example, in stackframe 19,
decode_str does not feature a call to PyUnicodeUCS2_Decode.
The most likely reason is that not all object files were
built with -g, so that some symbols are missing. I recommend
that you rebuild from scratch with --with-pydebug. Make sure
you have no object files left over from an earlier build.

If this causes the bug to disappear, configure with regular
options, and add -g to Makefile.pre manually. In either
case, verify that -g does get added to the compile commands.

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

Comment By: logistix (logistix)
Date: 2003-03-30 15:05

Message:
Logged In: YES 
user_id=699438

Okay, I lied.  I'm primarily a windows developer who's a bit  
new to the wonderful world of gdb!  It found the codec fine.   
libiconv was just the last library that gdb imported a symbol 
table from. 
  
The error actaully occurs on a realloc() to a list object.  I've  
attached the stack trace if it means anything.  
  
 man realloc also explains the error message: 
 
``modified (chunk-/page-) pointer.'' 
	The pointer passed to free or realloc has been modified. 
 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-30 03:05

Message:
Logged In: YES 
user_id=21627

It is surprising that it runs into iconv, as test_pep263
should use encodings.koi8_r.Codec, not the IconvCodec. What
do you get if you do

codecs.lookup("koi8-r")

In any case, the iconv codec (when used) should not crash.
It looks like there is some memory corruption going on.
However, without an OpenBSD system to debug libiconv, this
probably won't be found.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712056&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 07:36:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 23:36:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-694431 ] Python 2.3a2 Build fails on HP-UX11i
Message-ID: 

Bugs item #694431, was opened at 2003-02-27 15:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python 2.3a2 Build fails on HP-UX11i

Initial Comment:
While building Python 2.3a2 on HP-UX11i I got the 
following error:

ld -b build/temp.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.o -L/opt/python/lib -
L/usr/local/lib -o build/lib.hp-ux-B.11.11-
9000/785-2.3/_iconv_codec.sl
/usr/lib/dld.sl: Unresolved symbol: libiconv_open 
(code)  from build/lib.hp-ux-B.11.11-9000/785-
2.3/_iconv_codec.sl
sh[3]: 25624 Abort(coredump)
*** Error exit code 134


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

>Comment By: Richard Townsend (rptownsend)
Date: 2003-03-31 08:36

Message:
Logged In: YES 
user_id=200117

Yes, I was just trying to get Python to compile. I'm not 
aware that we have any need for the iconv codec module.

What is the best way to get the build process to omit it 
from the build?




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 21:55

Message:
Logged In: YES 
user_id=33168

This means the iconv_open() call is failing.  Unless you
know you need this module, you probably don't.  And if you
do need this module, you probably know more than I do. :-) 
So if you are just trying to get this working, I don't think
it's a big deal.  It seems to work on some HPUX machines.  I
suspect the reason the iconv_open() is failing is because of
a configuration on your machine.  This call is for
translating character sets.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 16:26

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I edited Modules/Setup line 483 like this:

_iconv_codec _iconv_codec.c -I/usr/include

I can now build Python! 

However test_iconv_codecs fails:

capulet:dist/src 
> ./python ./Lib/test/test_iconv_codecs.py
Traceback (most recent call last):
  File "./Lib/test/test_iconv_codecs.py", line 3, in ?
    import codecs, _iconv_codec
RuntimeError: can't initialize the _iconv_codec module: 
iconv_open() failed


I tried adding '-l:libdld.sl' to line 483 (as suggested by 
the man page) but
the test still fails.



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-26 14:43

Message:
Logged In: YES 
user_id=200117

Hi Neal,

I have now discovered that there is a different version of 
iconv.h on my workstation in /usr/local/include.

It appears to be part of the zlib package and it contains 
the pre-processor macros which are converting the 
iconv statements to libiconv.

It is being used instead of the one in /usr/include, 
because the compile command contains 
-I/usr/local/include 

Is there any easy to prevent this path from being added 
to the compile commands? 



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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-25 17:51

Message:
Logged In: YES 
user_id=200117

Neal,

The original error referred to unresolved 
symbol 'libiconv_open'.

The source module _iconv_codec.c contains calls to 
iconv_open(), not libiconv_open().

However, if I recompile it with the -E flag there is a pre-
processor substitution happening which is converting 
all instances of 'iconv' to 'libiconv'

Here I grepped the pre-processor output for 'iconv'...

extern int _libiconv_version;
typedef void* libiconv_t ;
extern libiconv_t  libiconv_open  (const char* tocode, 
const char* fromcode);
extern size_t libiconv  (libiconv_t  cd,  char* * inbuf, 
size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
extern int libiconv_close  (libiconv_t  cd);
extern int libiconvctl  (libiconv_t  cd, int request, void* 
argument);
    libiconv_t   enchdl, dechdl;
        if (libiconv (self->enchdl, (char**)&inp, &inplen, 
&out, &outlen)
        size_t res = libiconv (self->dechdl, (char**)&inp, 
&inplen, &out, &outlen);
    new->enchdl = new->dechdl = (libiconv_t )(-1);
    new->dechdl = libiconv_open ("ucs-2-internal" , 
new->encoding);
    if (new->dechdl == (libiconv_t )(-1)) {
    new->enchdl = libiconv_open (new->encoding, "ucs-
2-internal" );
    if (new->enchdl == (libiconv_t )(-1)) {
        libiconv_close (new->dechdl);
        new->dechdl = (libiconv_t )(-1);
    if (self->enchdl != (libiconv_t )-1)
        libiconv_close (self->enchdl);
    if (self->dechdl != (libiconv_t )-1)
        libiconv_close (self->dechdl);
    libiconv_t  hdl = libiconv_open ("ucs-2-
internal" , "ISO-8859-1");
    if (hdl == (libiconv_t )-1) {
    res = libiconv (hdl, &inptr, &insize, &outptr, &outsize);
        libiconv_close (hdl);
    libiconv_close (hdl);

Is this supposed to be happening??

If not, what could be causing it??



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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:52

Message:
Logged In: YES 
user_id=33168

Looking further into the python configure, I see that the
option is --with-dl-dld, however, this option is not
supported.  Can try to play with the build options to find
the magic that works on your version of HPUX?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 15:48

Message:
Logged In: YES 
user_id=33168

Richard, in the manpage it says that iconv has a dependancy
on libdld.sl.  Perhaps you need to configure python
--with-dld.  Can you try that?

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-04 17:09

Message:
Logged In: YES 
user_id=200117

Neal, I will try to help, but internet access is difficult at 
work so responses may not be prompt.

I had a look at the man page but it was not clear to me 
which library contains iconv_open. I will attach text 
copy of the man page for you.

I also include some nm output from libc.sl which refers 
to iconv_open, but I'm not sure if it means that it 
contains the code for the function.

Let me know if I can try anything else.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 22:15

Message:
Logged In: YES 
user_id=33168

Richard, can you help diagnose further since I can't
reproduce on HP-UX 11.00?  My initial guess is that
iconv_open is in a different location, therefore the linking
is faililng.  Does man iconv_open reveal what library
iconv_open is in?  To add directories, etc. to the
build/link of iconv, you will need to edit setup.py (or test
on the command line).   Check around line 620 in setup.py.

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

Comment By: Richard Townsend (rptownsend)
Date: 2003-03-03 09:14

Message:
Logged In: YES 
user_id=200117

Sorry for the delay but I had to download from CVS at 
home yesterday (Sunday 2nd) and build on HP-UX at 
work today.

Unfortunately I'm still getting the same linker error.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 17:37

Message:
Logged In: YES 
user_id=33168

This iconv_codec problem may be fixed.  Please test with
current CVS to verify.
See SF bug #690012.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-28 03:45

Message:
Logged In: YES 
user_id=33168

Richard, can you try the latest version from CVS.  I don't
have this problem on hp-ux-B.11.00-9000/829

I do have a problem with readline, but I think that's
specific to the machine I'm building on.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=694431&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 07:40:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 30 Mar 2003 23:40:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 22:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 09:29:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 01:29:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-710197 ] initialisation problem with dict.fromkeys()
Message-ID: 

Bugs item #710197, was opened at 2003-03-26 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470

Category: None
Group: Python 2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Frederic Sohm (fsms)
Assigned to: Nobody/Anonymous (nobody)
Summary: initialisation problem with dict.fromkeys()

Initial Comment:
I have a problem of initialization of dictionary with the new method  
dict.fromkeys(sequence [, defaults]) when defaults is a list.  
  
here an example :  
  
Python 2.3a2 (#1, Feb 21 2003, 14:28:59)   
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2  
Type "copyright", "credits" or "license" for more information.  
IDLEfork 0.9a2  
>>> a = {}.fromkeys([0, 1], [ ])  
>>> a[0]  
[ ]  
>>> a[1]  
[ ]  
>>> a[0] += [2]  
>>> a[0]  
[2]  
>>> a[1]  
[2]  
>>> a[1] is a[0]  
True  
>>> a[0].append(3)  
>>> a[0]  
[2, 3]  
>>> a[1]  
[2, 3]  
etc... same thing if I use list() instead of [ ] 
  
the same list seems to be assigned to all the keys.  
when using string, tuple... it is normal (or what I would expect at 
least) : 
>>> b = {}.fromkeys([0,1], '') 
>>> b[0] 
'' 
>>> b[1] 
'' 
>>> b[0] += '2' 
>>> b[0] 
'2' 
>>> b[1] 
'' 
>>>b[0] is b[1] 
False 

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 19:21

Message:
Logged In: YES 
user_id=6380

This is not a bug but a simple aliasing problem; all keys
will share the same *object* for their initial value.

Write help@python.org or post to comp.lang.python if you
want to learn more.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 09:35:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 01:35:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-710197 ] initialisation problem with dict.fromkeys()
Message-ID: 

Bugs item #710197, was opened at 2003-03-26 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470

Category: None
Group: Python 2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Frederic Sohm (fsms)
Assigned to: Nobody/Anonymous (nobody)
Summary: initialisation problem with dict.fromkeys()

Initial Comment:
I have a problem of initialization of dictionary with the new method  
dict.fromkeys(sequence [, defaults]) when defaults is a list.  
  
here an example :  
  
Python 2.3a2 (#1, Feb 21 2003, 14:28:59)   
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2  
Type "copyright", "credits" or "license" for more information.  
IDLEfork 0.9a2  
>>> a = {}.fromkeys([0, 1], [ ])  
>>> a[0]  
[ ]  
>>> a[1]  
[ ]  
>>> a[0] += [2]  
>>> a[0]  
[2]  
>>> a[1]  
[2]  
>>> a[1] is a[0]  
True  
>>> a[0].append(3)  
>>> a[0]  
[2, 3]  
>>> a[1]  
[2, 3]  
etc... same thing if I use list() instead of [ ] 
  
the same list seems to be assigned to all the keys.  
when using string, tuple... it is normal (or what I would expect at 
least) : 
>>> b = {}.fromkeys([0,1], '') 
>>> b[0] 
'' 
>>> b[1] 
'' 
>>> b[0] += '2' 
>>> b[0] 
'2' 
>>> b[1] 
'' 
>>>b[0] is b[1] 
False 

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

>Comment By: Frederic Sohm (fsms)
Date: 2003-03-31 09:35

Message:
Logged In: YES 
user_id=742767

ok sorry for the bother.
thank you for the response.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-28 19:21

Message:
Logged In: YES 
user_id=6380

This is not a bug but a simple aliasing problem; all keys
will share the same *object* for their initial value.

Write help@python.org or post to comp.lang.python if you
want to learn more.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=710197&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 10:44:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 02:44:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-683938 ] HTMLParser attribute parsing bug
Message-ID: 

Bugs item #683938, was opened at 2003-02-10 15:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683938&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser attribute parsing bug

Initial Comment:
HTMLParser (reportedly)  fails to parse this construct:

P

(Note that a required space between the two attributes
of the "a" tag has been omitted).  The W3C validator
appearantly treats this differently, so there's no
point in arguing the letter of the law.

Assigned to me.

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

Comment By: Bastian Kleineidam (calvin)
Date: 2003-03-31 12:44

Message:
Logged In: YES 
user_id=9205

HTMLParser (and lots of other parsers I tried) has
definitely limits when it comes to error recovering. I dont
know if its good to put further development effort in
HTMLParser as it will IMHO never reach the ability to cope
with all the crappy HTML out there.
If you really want to have a html parser in Python, I
suggest you look at my htmlsax module packaged with
linkchecker (linkchecker.sf.net) and webcleaner
(webcleaner.sf.net), the parser is tested with lots of real
world examples.
The parser packaged with linkchecker has line counting, the
one with webcleaner not.

Cheers, Bastian


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683938&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 13:33:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 05:33:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 15:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 14:22:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 06:22:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 22:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Just van Rossum (jvr)
Date: 2003-03-31 16:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 15:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 00:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 23:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 14:32:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 06:32:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
Message-ID: 

Bugs item #712322, was opened at 2003-03-30 15:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_zipimport failing on ia64 (at least)

Initial Comment:
test_zipimport is failing on the snake-farm.  I'm
pretty sure this test worked before.  The only
difference is the file ends in .py vs. .pyc.  I don't
know what changed recently which would have cause this.

http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt

test test_zipimport failed -- Traceback (most recent
call last):
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
    self.doTest(pyc_ext, files, TESTMOD)
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
    self.assertEquals(file, os.path.join(TEMP_ZIP,
  File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32

Message:
Logged In: YES 
user_id=33168

Yes, I believe it worked more recently, but I could be
wrong...  I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed.  I'll keep trying too.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22

Message:
Logged In: YES 
user_id=92689

dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33

Message:
Logged In: YES 
user_id=33168

It is also broken on AIX which I do have access to.  I'm
trying to determine what broke it.  One guess is dictionary
order.  I'm not sure if the test relies on .pyc being
written before .py as a result of file.items().  It is
broken on 3/26.  Unfortunately it takes a very long time to
build on these boxes (hours).  Let me know if you have any
idea of what might have recently changed to break zipimports.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40

Message:
Logged In: YES 
user_id=92689

Then how are we/am I supposed to fix this? Assigning to None.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32

Message:
Logged In: YES 
user_id=33168

Unfortunately, I don't have access to the boxes where this
is failling.  The only possibility would be in the compaq
(hp) test drive machines.

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

Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03

Message:
Logged In: YES 
user_id=92689

Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470


From noreply@sourceforge.net  Mon Mar 31 22:00:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 31 Mar 2003 14:00:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-712975 ] Cannot change the class of a list
Message-ID: 

Bugs item #712975, was opened at 2003-03-31 22:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712975&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiba (jiba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot change the class of a list

Initial Comment:
The class of list (or dict) can no longer be changed in
Python 2.3a2 ; this was possible with Python 2.2.2 (as
long as the new class extend list and has no slot).
When doing so ([].__class__ = ...), i get this error :

TypeError: __class__ assignment: only for heap types


Not being able to change the class of non-mutable
object (e.g. int, float or tuple) is AMHO not a great
loss, but list and dict ARE mutable, and so changing
their class does have a sens !

Typically it can be used to observed a list that you
have not created yourself (see atteched script); i was
relying a lot on such observation features.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712975&group_id=5470